Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 301575

Summary:	launching JBoss from the servers view results in a modal dialog
Product:	[Eclipse Project] JDT	Reporter:	David Green <greensopinion>
Component:	Debug	Assignee:	JDT-Debug-Inbox <jdt-debug-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	Michael_Rennie
Version:	3.6
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X
Whiteboard:	stalebug

Description David Green

2010-02-02 13:48:04 EST

After launching JBoss from the servers view a modal dialog is presented asking for the source for java.net.URL.  This dialog is seemingly unnecessary, since I have no editors open and I don't care about the source for java.net.URL.  The dialog is also annoying, since I restart JBoss regularly and it prevents JBoss from starting up until the dialog is dismissed.

Using jconsole I found the stack trace of the code that instigates the dialog.  It looks like it's related to a breakpoint, however when I look at my breakpoints view there are none.

Name: Worker-5
State: TIMED_WAITING on org.eclipse.ui.internal.Semaphore@1a7ab99c
Total blocked: 791  Total waited: 1,174

Stack trace: 
java.lang.Object.wait(Native Method)
org.eclipse.ui.internal.Semaphore.acquire(Semaphore.java:43)
org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:168)
org.eclipse.swt.widgets.Display.syncExec(Display.java:4111)
org.eclipse.debug.internal.ui.sourcelookup.Prompter.handleStatus(Prompter.java:79)
org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.resolveSourceElement(AbstractSourceLookupDirector.java:534)
org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.getSourceElement(AbstractSourceLookupDirector.java:762)
org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility.lookup(SourceLookupFacility.java:148)
org.eclipse.debug.ui.DebugUITools.lookupSource(DebugUITools.java:777)
org.eclipse.jdt.internal.debug.ui.JavaDebugOptionsManager.getProblem(JavaDebugOptionsManager.java:577)
org.eclipse.jdt.internal.debug.ui.breakpoints.SuspendOnCompilationErrorListener.breakpointHit(SuspendOnCompilationErrorListener.java:67)
org.eclipse.jdt.internal.debug.core.breakpoints.BreakpointListenerManager$JavaBreakpointListenerProxy.breakpointHit(BreakpointListenerManager.java:135)
org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$HitNotifier.run(JDIDebugPlugin.java:644)
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$AbstractNotifier.notifyListeners(JDIDebugPlugin.java:466)
org.eclipse.jdt.internal.debug.core.JDIDebugPlugin$HitNotifier.notifyHit(JDIDebugPlugin.java:658)
org.eclipse.jdt.internal.debug.core.JDIDebugPlugin.fireBreakpointHit(JDIDebugPlugin.java:407)
org.eclipse.jdt.internal.debug.core.model.JDIThread.handleSuspendForBreakpoint(JDIThread.java:1130)
org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.suspend(JavaBreakpoint.java:363)
org.eclipse.jdt.internal.debug.core.breakpoints.JavaExceptionBreakpoint.handleBreakpointEvent(JavaExceptionBreakpoint.java:348)
org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent(JavaBreakpoint.java:288)
org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:155)
org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:104)
org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:250)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Comment 1 David Green

2010-02-02 13:49:52 EST

based on the stack trace moving this to JDT

Comment 2 David Green

2010-02-02 13:50:55 EST

Version: 3.6.0
Build id: I20100129-1300

Comment 3 Michael Rennie

2010-02-02 14:04:33 EST

Looking at the stacktrace, it is suspending because you have the preference 
"Java -> Debug -> Suspend execution on compilation errors" enabled. This preference sets a 'virtual' breakpoint (which you will never see in the view) that suspends when you have compilation errors in your workspace that affect the current launch.

Comment 4 David Green

2010-02-02 14:18:48 EST

(In reply to comment #3)
> Looking at the stacktrace, it is suspending because you have the preference 
> "Java -> Debug -> Suspend execution on compilation errors" enabled.

Yes I do have that setting enabled.  From what I can see that is the default setting.

A couple of things seem strange to me about that:
* there are no compilation errors in my projects
* why would it be setting a breakpoint in java.net.URL, when it obviously has no compilation errors (it's in the rt.jar)

Comment 5 Michael Rennie

2010-02-02 14:30:32 EST

(In reply to comment #4)

> A couple of things seem strange to me about that:
> * there are no compilation errors in my projects

That is odd indeed. 

> * why would it be setting a breakpoint in java.net.URL, when it obviously has
> no compilation errors (it's in the rt.jar)

Like I said it sets (for lack of a better term) a virtual breakpoint - meaning it will suspend execution like a breakpoint. 

It could be that your shapshot is not actually showing it suspending on a compilation error, just showing the notification of listener and that it is actually suspending on the exception breakpoint mentioned at the start of the stacktrace. Do you have any Exception breakpoints set? 

org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.suspend(JavaBreakpoint.java:363)
org.eclipse.jdt.internal.debug.core.breakpoints.JavaExceptionBreakpoint.handleBreakpointEvent(JavaExceptionBreakpoint.java:348)
org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent(JavaBreakpoint.java:288)

Comment 6 David Green

2010-02-06 02:39:13 EST

(In reply to comment #5)
> Do you have any Exception breakpoints set?

no, no exception breakpoints.

Comment 7 Eclipse Genie

2020-03-16 10:32:52 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.