Comment 1 Pawel Piech 2011-08-16 16:32:58 EDT

This is another one in long list of such bugs.  I think the only simple remedy is to swallow the exception since such race conditions are expected.  

Changing the break listeners to be called on POST_CHANGE as discussed in bug 269182 would go a long way to reduce this problem.  The down side of using POST_CHANGE is that listeners would not be able to modify the breakpoints inside the listener.  IMO, this would be a good thing as this practice leads to deadlocks such as bug 342219.

Comment 2 Eugene Tarassov 2011-08-16 17:31:36 EDT

(In reply to comment #1)
> ... such race conditions are expected.

Not sure what you mean. Are you saying it is meant to fail by design?

Why not fix it by providing correct scheduling rule?

Current code to get scheduling rule for a marker looks like this:
	public ISchedulingRule markerRule(IResource resource) {
		//team hook currently cannot change this rule
		return null;
	}
It appears intentionally broken. Why not fix it?

Comment 3 Pawel Piech 2011-08-16 23:18:43 EDT

(In reply to comment #2)
> It appears intentionally broken. Why not fix it?

Breakpoint listeners are called asynchronously some time after breakpoints are created/changed/removed (usually 100 ms).  So it's possible that by the time the listener is called, the breakpoint marker is already deleted.  Breakpoint listeners have to guard against this race condition by checking IBreakpoint.getMarker() != null.  So yes, this failure allowed by design, but JDT code should guard against it and not log the exception.

The null scheduling effectively locks the entire resource tree, so it has no effect on this race condition.

Comment 4 Eugene Tarassov 2011-08-17 14:45:42 EDT

(In reply to comment #3)

> Breakpoint listeners are called asynchronously some time after breakpoints are
> created/changed/removed...

Yes, but this is a problem with BreakpointManagerContentProvider listeners. It also needs to be solved. However, the stack trace contains BreakpointManager listener, which is called synchronously, but still fails because of the racing. 

> Breakpoint listeners have to guard against this race condition by checking
> IBreakpoint.getMarker() != null.

This will not work. The racing can happen between that "if" and next statement, so the code will fail, just less frequently.

> The null scheduling effectively locks the entire resource tree,...

I could not find a code that treats null as a lock for the entire resource tree. Could you give a reference? Even if the intention was to lock the entire resource tree, it appears not working as expected. According to the stack trace, the marker was deleted while the job was still executing BreakpointManager.addBreakpoint() method.

> So yes, this failure allowed by design, but
> JDT code should guard against it and not log the exception.

I'm really surprised that you suggest hiding design flaws instead of fixing them.

In any case, I don't see any problems with serializing breakpoints add/delete/notify jobs. It is a matter of crafting a single scheduling rule that should be used to run all those jobs. It would ensure mutually exclusive access to breakpoints data, and it would fix all those problems.

Comment 5 Michael Rennie 2011-08-22 10:16:23 EDT

*** Bug 329951 has been marked as a duplicate of this bug. ***

Comment 6 Michael Rennie 2011-08-22 10:49:51 EDT

(In reply to comment #4)

> In any case, I don't see any problems with serializing breakpoints
> add/delete/notify jobs. It is a matter of crafting a single scheduling rule
> that should be used to run all those jobs. It would ensure mutually exclusive
> access to breakpoints data, and it would fix all those problems.

I agree, we need a better way to ensure that once a breakpoint has been removed there is no transient infos accessible while we are waiting for the manager to be updated.

We have had issues with our breakpoints listeners all the way back to bug 10736...

Comment 7 Michael Rennie 2013-02-06 09:27:54 EST

*** Bug 393334 has been marked as a duplicate of this bug. ***

Comment 8 Dani Megert 2014-01-15 03:38:49 EST

*** Bug 292251 has been marked as a duplicate of this bug. ***

Comment 9 Patric Rufflar 2019-11-18 06:50:41 EST

Still present in 2019-09:

org.eclipse.debug.core.DebugException: Breakpoint does not have an associated marker.
	at org.eclipse.debug.core.model.Breakpoint.ensureMarker(Breakpoint.java:323)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.getLineNumber(JavaLineBreakpoint.java:257)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.newRequests(JavaLineBreakpoint.java:298)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.createRequest(JavaBreakpoint.java:517)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.createRequests(JavaBreakpoint.java:657)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.addToTarget(JavaBreakpoint.java:615)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaLineBreakpoint.addToTarget(JavaLineBreakpoint.java:180)
	at org.eclipse.jdt.internal.debug.core.model.JDIDebugTarget.breakpointManagerEnablementChanged(JDIDebugTarget.java:2857)
	at org.eclipse.debug.internal.core.BreakpointManager$BreakpointManagerNotifier.run(BreakpointManager.java:1188)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.debug.internal.core.BreakpointManager$BreakpointManagerNotifier.notify(BreakpointManager.java:1200)
	at org.eclipse.debug.internal.core.BreakpointManager.setEnabled(BreakpointManager.java:1157)
	at org.eclipse.debug.internal.ui.actions.breakpoints.SkipAllBreakpointsAction$1.run(SkipAllBreakpointsAction.java:94)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Comment 10 Sarika Sinha 2019-11-20 01:23:05 EST

Thanks for confirming.
Anyone interested in working on this?

Comment 11 Eclipse Genie 2021-11-10 05:58:26 EST

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.

If you have further information on the current state of the bug, please add it. 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.

Comment 12 Patric Rufflar 2021-11-10 17:51:10 EST

It's still relevant for us.

Comment 13 Sarika Sinha 2021-11-11 00:48:25 EST

Will be looking at the related bugs in 4.23.

Comment 14 Andreas Paepcke 2023-12-24 13:18:55 EST

The bug is still relevant in

Eclipse IDE for Enterprise Java and Web Developers (includes Incubating components)

Version: 2023-12 (4.30.0)
Build id: 20231201-2043

!ENTRY org.python.pydev.debug 4 4 2023-12-24 09:56:19.031
!MESSAGE getImage error
!STACK 1
org.eclipse.debug.core.DebugException: Breakpoint_no_associated_marker
	at org.python.pydev.debug.model.PyBreakpoint.ensureMarker(PyBreakpoint.java:215)
	at org.python.pydev.debug.model.PyBreakpoint.isConditionEnabled(PyBreakpoint.java:190)
	at org.python.pydev.debug.model.PyDebugModelPresentation.getImage(PyDebugModelPresentation.java:102)
	at org.eclipse.debug.internal.ui.LazyModelPresentation.getImage(LazyModelPresentation.java:129)
	at org.eclipse.debug.internal.ui.DelegatingModelPresentation.getImage(DelegatingModelPresentation.java:138)
	at org.eclipse.debug.internal.ui.views.launch.DebugElementHelper.getImageDescriptor(DebugElementHelper.java:73)
	at org.eclipse.debug.internal.ui.model.elements.DebugElementLabelProvider.getImageDescriptor(DebugElementLabelProvider.java:80)
	at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.getImageDescriptor(ElementLabelProvider.java:274)
	at org.eclipse.debug.internal.ui.model.elements.BreakpointLabelProvider.getImageDescriptor(BreakpointLabelProvider.java:43)
	at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:201)
	at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:147)
	at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
!SUBENTRY 1 org.eclipse.debug.core 4 5012 2023-12-24 09:56:19.031
!MESSAGE Breakpoint_no_associated_marker