Race condition in ConsoleColorProvider.connect()

[trancexpress]

Seen in: #596

Reproduction steps are similar to: #2637

1. Set a breakpoint at: org.eclipse.debug.ui.console.ConsoleColorProvider.connect(IProcess, IConsole)
2. Debug Eclipse, make sure the Console view is open.
3. In the debuggee, create a snippet:

public class Test3 {

	public static void main(String[] args) throws InterruptedException {
		Thread.sleep(60_000);
	}
}

4. Launch this snippet twice.
5. Observe two threads suspended at the breakpoint.
6. Step over in the 1st thread until if (streamsProxy != null) {, do the same for the 2nd thread.
7. Continue stepping until this state is reached:

"Worker-7: Creating console for /usr/lib/jvm/java-21-openjdk/bin/java (Apr 30, 2026, 11:56:11 AM) [pid: 70092]" #79 [69171] prio=5 os_prio=0 cpu=72.35ms elapsed=122.76s tid=0x00007fea50003e50 nid=69171 runnable  [0x00007feaecea0000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.connect(ProcessConsole.java:797)
        - locked <0x0000000720e4cde8> (a org.eclipse.debug.internal.core.OutputStreamMonitor)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.connect(ProcessConsole.java:760)
        at org.eclipse.debug.ui.console.ConsoleColorProvider.connect(ConsoleColorProvider.java:43)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.<init>(ProcessConsole.java:274)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager$ConsoleCreation.run(ProcessConsoleManager.java:74)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

"Worker-10: Creating console for /usr/lib/jvm/java-21-openjdk/bin/java (Apr 30, 2026, 11:56:09 AM) [pid: 70044]" #82 [69174] prio=5 os_prio=0 cpu=41.39ms elapsed=122.75s tid=0x00007fea4c004610 nid=69174 runnable  [0x00007feaeca9e000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.connect(ProcessConsole.java:797)
        - locked <0x000000072376c7a8> (a org.eclipse.debug.internal.core.OutputStreamMonitor)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.connect(ProcessConsole.java:760)
        at org.eclipse.debug.ui.console.ConsoleColorProvider.connect(ConsoleColorProvider.java:43)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsole.<init>(ProcessConsole.java:274)
        at org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager$ConsoleCreation.run(ProcessConsoleManager.java:74)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Both threads are not at fStreamListeners.add(listener), on the same ArrayList fStreamListeners.

[trancexpress]

Aside from #596, another side effect here would be not calling IConsole.connect(IStreamsProxy) or wrong output from ConsoleColorProvider.isReadOnly().

I'm not sure how ProcessConsoleManager.fDefaultColorProvider is meant to work, considering that its shared between multiple ConsoleCreation jobs.

[fedejeanne]

I'm not sure how ProcessConsoleManager.fDefaultColorProvider is meant to work, considering that its shared between multiple ConsoleCreation jobs.

I agree, this seems like an overlook in the implementation. I see in org.eclipse.debug.internal.ui.DebugUIPlugin.getProcessConsoleManager() that fProcessConsoleManager is supposed to be a singleton (which is fine)...

eclipse.platform/debug/org.eclipse.debug.ui/ui/org/eclipse/debug/internal/ui/DebugUIPlugin.java

Lines 907 to 912 in b45a8f4

	public ProcessConsoleManager getProcessConsoleManager() {
	if (fProcessConsoleManager == null) {
	fProcessConsoleManager = new ProcessConsoleManager();
	}
	return fProcessConsoleManager;
	}

... but the ConsoleCreation job is not a singleton, which is why debugging and stopping inside methods like org.eclipse.debug.internal.ui.views.console.ProcessConsoleManager.getColorProvider(String) clearly shows 2 threads racing into it (see #2637 (comment)) and creates this mess.

eclipse.platform/debug/org.eclipse.debug.ui/ui/org/eclipse/debug/internal/ui/views/console/ProcessConsoleManager.java

Lines 198 to 202 in b45a8f4

	if (getConsoleDocument(process) == null) {
	// create a new console in a separated thread, see bug 355011.
	Job job = new ConsoleCreation(launch, process);
	job.schedule();
	}

A better approach would be either synchronize the methods from ProcessConsoleManager that need to be accessed by the ConsoleCreation job (brittle) or make the ConsoleCreation job a singleton and simply add requests to a work queue so that the job process them sequentially.

WDYT @trancexpress ?

[fedejeanne]

The change was introduced in a2f3fea and it fixed the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=355011.

Maybe @iloveeclipse can better judge which approach is better suited?

[trancexpress]

Simple options I see:

• add a mutually exclusive rule to ConsoleCreation, so that one job runs at a time
• make ConsoleColorProvider.connect use process and console instead of fProcess resp. fConsole

This doesn't change the behavior of ConsoleColorProvider.isReadOnly(), which will work with whatever job managed to set fProcess last... I see no callers to this method though. Maybe its useful for when the color provided is from an extension. I'm guessing in that case the problem is seen with the implementers, considering ConsoleColorProvider encourages extension in its JavaDoc.

I don't know honestly, the design here is odd even without the job.

[iloveeclipse]

The change was introduced in a2f3fea and it fixed the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=355011.

Maybe @iloveeclipse can better judge which approach is better suited?

OMG, it's already 8 years ago... But looking at the old bug & code, now we can do this: #2642 to solve deadlock we had before :-)

I have no time now to check what the rest of the code does with ConsoleColorProvider or ProcessConsoleManager does with colors etc, feel free to provide a PR, we can review that.