Use workspace root modification rule when removing all breakpoints by trancexpress · Pull Request #2218 · eclipse-platform/eclipse.platform

trancexpress · 2025-10-28T12:35:07Z

When removing breakpoints, its possible that another job is accessing the breakpoint marker. This can result in an exception, since removing a breakpoint will also remove the marker.

This change moves breakpoint removal code in a job that holds a workspace root modification rule, if the current thread does not hold a matching rule.

Fixes: #2217

trancexpress · 2025-10-28T12:35:16Z

This revives the now gone: https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/165753

github-actions · 2025-10-28T13:07:57Z

Test Results

1 977 files + 27 1 977 suites +27 1h 29m 7s ⏱️ -56s
4 743 tests ± 0 4 719 ✅ + 1 24 💤 ±0 0 ❌ - 1
14 229 runs +153 14 047 ✅ +154 182 💤 ±0 0 ❌ - 1

Results for commit aff8b5b. ± Comparison against base commit 8594fad.

♻️ This comment has been updated with latest results.

mickaelistria · 2025-10-30T08:13:46Z

Would just passing the rule MultiRule.combine(update.stream().map(getWorkspace()::markerRule).toArray(ISchedulingRule[]::new)) prevent from comcurrent access without blocking too much?

trancexpress · 2025-10-30T08:39:25Z

Would just passing the rule MultiRule.combine(update.stream().map(getWorkspace()::markerRule).toArray(ISchedulingRule[]::new)) prevent from comcurrent access without blocking too much?

I'll check when I can, I'd have more confidence in the change that way.

If you mean org.eclipse.core.resources.IResourceRuleFactory.markerRule(IResource), it returns null always?

trancexpress · 2025-10-30T15:52:25Z

The MultiRule suggestion works, I wonder if we should use it also in JavaDebugOptionsManager... eclipse-jdt/eclipse.jdt.debug@897972b

When testing the change, I noticed its not enough to prevent the logged error. This code is removing the info:

"Worker-18: Remove Breakpoints" #131 [77058] prio=5 os_prio=0 cpu=418.64ms elapsed=1291.43s tid=0x00007f5d68000de0 nid=77058 at breakpoint [0x00007f5da91ee000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.core.internal.resources.MarkerManager.removeMarker(MarkerManager.java:513)
        at org.eclipse.core.internal.resources.Marker.delete(Marker.java:84)
        at org.eclipse.ui.ide.undo.AbstractMarkersOperation.deleteMarkers(AbstractMarkersOperation.java:117)
        at org.eclipse.ui.ide.undo.DeleteMarkersOperation.doExecute(DeleteMarkersOperation.java:61)
        at org.eclipse.debug.internal.ui.views.breakpoints.DeleteBreakpointMarkersOperation.doExecute(DeleteBreakpointMarkersOperation.java:48)
        at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation.lambda$0(AbstractWorkspaceOperation.java:199)
        at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation$$Lambda/0x00007f5e94bdc8c8.run(Unknown Source)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2505)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2533)
        at org.eclipse.ui.ide.undo.AbstractWorkspaceOperation.execute(AbstractWorkspaceOperation.java:199)
        at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:488)
        at org.eclipse.debug.ui.DebugUITools.deleteBreakpoints(DebugUITools.java:353)
        at org.eclipse.debug.internal.ui.actions.breakpoints.RemoveAllBreakpointsAction$1.run(RemoveAllBreakpointsAction.java:126)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

So apparently there is more to change...

When removing breakpoints, its possible that another job is accessing the breakpoint marker. This can result in an exception, since removing a breakpoint will also remove the marker. This change adds a scheduling MultiRule to the marker removal operation. Fixes: eclipse-platform#2217

eclipse-platform-bot · 2026-02-20T11:53:01Z

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

debug/org.eclipse.debug.core/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 357760ec942bfcac156465ed42d4681a497096d8 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Fri, 20 Feb 2026 11:52:40 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/debug/org.eclipse.debug.core/META-INF/MANIFEST.MF b/debug/org.eclipse.debug.core/META-INF/MANIFEST.MF
index 5367db6616..d63fbfc45b 100644
--- a/debug/org.eclipse.debug.core/META-INF/MANIFEST.MF
+++ b/debug/org.eclipse.debug.core/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.debug.core; singleton:=true
-Bundle-Version: 3.23.200.qualifier
+Bundle-Version: 3.23.300.qualifier
 Bundle-Activator: org.eclipse.debug.core.DebugPlugin
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.52.0

Further information are available in Common Build Issues - Missing version increments.

trancexpress · 2026-02-20T11:54:48Z

debug/org.eclipse.debug.core/core/org/eclipse/debug/internal/core/BreakpointManager.java

 	}
+
+	private static ISchedulingRule getMarkerRule(IResource resource) {
+		return getWorkspace().getRuleFactory().modifyRule(resource);


I'm not sure which rule we should use here, as mentioned before in the PR org.eclipse.core.internal.resources.Rules.markerRule(IResource) returns null:

/** * Obtains the scheduling rule from the appropriate factory for a marker change operation. */ @Override public ISchedulingRule markerRule(IResource resource) { //team hook currently cannot change this rule return null; }

Can you please add this to the method javadoc?

trancexpress · 2026-02-20T11:55:41Z

When testing the change, I noticed its not enough to prevent the logged error. This code is removing the info:

When testing again, I'm not running into this error. Maybe something changed...

Anyway, if we can, lets proceed here. If there are more sporadic marker errors, we can always open another issue.

iloveeclipse · 2026-02-20T12:34:42Z

As commented on other PR, see this discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=66538.

I wonder if the org.eclipse.debug.core.model.Breakpoint.getMarkerRule() should be used instead and the underlined logic fixed where needed in one place for all breakpoint clients.

trancexpress · 2026-02-20T12:47:07Z

As commented on other PR, see this discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=66538.

I wonder if the org.eclipse.debug.core.model.Breakpoint.getMarkerRule() should be used instead and the underlined logic fixed where needed in one place for all breakpoint clients.

The marker rule seems to be a placeholder for a change that was never done, or am I seeing it wrong?

I don't think we can fix this even for JavaDebugOptionsManager, since it does multiple operations on the marker... check if the marker still exists, then do something with it. Maybe if Marker.setAttribute() held a lock on the respective rule, and we catch the thrown exception if it no longer exists...

trancexpress force-pushed the gh2217 branch from 00994ba to 9fd75cf Compare February 20, 2026 11:45

trancexpress marked this pull request as ready for review February 20, 2026 11:51

Version bump(s) for 4.39 stream

aff8b5b

trancexpress commented Feb 20, 2026

View reviewed changes

trancexpress requested a review from iloveeclipse February 20, 2026 11:55

trancexpress mentioned this pull request Feb 20, 2026

Narrow down scheduling rule in JavaDebugOptionsManager.updateBreakpointMessages() eclipse-jdt/eclipse.jdt.debug#872

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use workspace root modification rule when removing all breakpoints#2218

Use workspace root modification rule when removing all breakpoints#2218
trancexpress wants to merge 2 commits intoeclipse-platform:masterfrom
trancexpress:gh2217

trancexpress commented Oct 28, 2025

Uh oh!

trancexpress commented Oct 28, 2025

Uh oh!

github-actions bot commented Oct 28, 2025 •

edited

Loading

Uh oh!

mickaelistria commented Oct 30, 2025

Uh oh!

trancexpress commented Oct 30, 2025 •

edited

Loading

Uh oh!

trancexpress commented Oct 30, 2025

Uh oh!

eclipse-platform-bot commented Feb 20, 2026

Uh oh!

trancexpress Feb 20, 2026

Uh oh!

iloveeclipse Feb 20, 2026

Uh oh!

trancexpress commented Feb 20, 2026

Uh oh!

iloveeclipse commented Feb 20, 2026 •

edited

Loading

Uh oh!

trancexpress commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

Conversation

trancexpress commented Oct 28, 2025

Uh oh!

trancexpress commented Oct 28, 2025

Uh oh!

github-actions bot commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

mickaelistria commented Oct 30, 2025

Uh oh!

trancexpress commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trancexpress commented Oct 30, 2025

Uh oh!

eclipse-platform-bot commented Feb 20, 2026

Uh oh!

trancexpress Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

iloveeclipse Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

trancexpress commented Feb 20, 2026

Uh oh!

iloveeclipse commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

trancexpress commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

github-actions bot commented Oct 28, 2025 •

edited

Loading

trancexpress commented Oct 30, 2025 •

edited

Loading

iloveeclipse commented Feb 20, 2026 •

edited

Loading