IOConsoleTests: AutoRegisterSchemeHandlersJob still running on I20240905-0340 MacOS

[jukzi]

https://download.eclipse.org/eclipse/downloads/drops4/I20240905-0340/testresults/html/org.eclipse.debug.tests_ep434I-unit-macM1-java17_macosx.cocoa.aarch64_17.html

org.opentest4j.MultipleFailuresError: Multiple Failures (2 failures)
java.lang.AssertionError: Test triggered errors in IOConsole
java.lang.AssertionError: Test triggered errors in IOConsole
Suppressed: java.lang.AssertionError: Test triggered errors in IOConsole
at org.eclipse.debug.tests.console.IOConsoleTests.lambda$1(IOConsoleTests.java:138)
at java.base/java.util.concurrent.ConcurrentLinkedQueue.forEachFrom(ConcurrentLinkedQueue.java:1037)
at java.base/java.util.concurrent.ConcurrentLinkedQueue.forEach(ConcurrentLinkedQueue.java:1054)
at org.eclipse.debug.tests.console.IOConsoleTests.assertNoError(IOConsoleTests.java:136)
at org.eclipse.debug.tests.console.IOConsoleTests.testBackspaceControlCharacter(IOConsoleTests.java:542)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
Caused by: java.lang.RuntimeException: Some job is still running or waiting to run:
'AutoRegisterSchemeHandlersJob(19)'/org.eclipse.urischeme.AutoRegisterSchemeHandlersJob
thread info: "Worker-2: AutoRegisterSchemeHandlersJob" prio=5 Id=47 RUNNABLE
at java.base@17/java.lang.String.substring(String.java:2710)
at java.base@17/java.lang.String.subSequence(String.java:2742)
at java.base@17/java.util.regex.Pattern.split(Pattern.java:1272)
at java.base@17/java.lang.String.split(String.java:3150)
at java.base@17/java.lang.String.split(String.java:3196)
at org.eclipse.urischeme.internal.registration.RegistrationMacOsX.determineHandlerLocation(RegistrationMacOsX.java:88)
at org.eclipse.urischeme.internal.registration.RegistrationMacOsX.getSchemesInformation(RegistrationMacOsX.java:67)
at org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.run(AutoRegisterSchemeHandlersJob.java:84)
..

seems unclear to me if AutoRegisterSchemeHandlersJob is to slow or if there is another rootcause that failed the test

[jukzi]

failed on https://download.eclipse.org/eclipse/downloads/drops4/I20240905-1800 too

[jukzi]

https://download.eclipse.org/eclipse/downloads/drops4/I20240905-0340/testresults/ep434I-unit-mac64-java17_macosx.cocoa.x86_64_17/org.eclipse.debug.tests.AutomatedSuite.txt
contains 1020 log entries like

Some job is still running or waiting to run: 
'AutoRegisterSchemeHandlersJob(19)'/org.eclipse.urischeme.AutoRegisterSchemeHandlersJob
thread info: "Worker-2: AutoRegisterSchemeHandlersJob" prio=5 Id=45 RUNNABLE

[jukzi]

@BeckerWdf could you please take a look, as you have recently worked on AutoRegisterSchemeHandlersJob on macos

[sratz]

The job itself has not been changed recently. But the job itself is rather expensive, especially on macOS.

It is scheduled in org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.initialize(IWorkbenchConfigurer), but this is unnecessarily expensive to do for each and every unit test.

I wonder if we could detect that we are running unit tests and not run the job in that case.

Additionally, we should probably also not run it in case of Platform.inDevelopmentMode().

[jukzi]

Note that the failures also complain about CIRCULAR REFERENCE -whatever that means

Caused by: [CIRCULAR REFERENCE: java.lang.RuntimeException: Some job is still running or waiting to run:
'AutoRegisterSchemeHandlersJob(19)'/org.eclipse.urischeme.AutoRegisterSchemeHandlersJob
thread info: "Worker-2: AutoRegisterSchemeHandlersJob" prio=5 Id=47 RUNNABLE
at java.base@17/java.io.FileInputStream.readBytes(Native Method)
at java.base@17/java.io.FileInputStream.read(FileInputStream.java:276)
at java.base@17/java.io.BufferedInputStream.fill(BufferedInputStream.java:244)
at java.base@17/java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.base@17/java.io.BufferedInputStream.read(BufferedInputStream.java:343)
- locked java.lang.ProcessImpl$ProcessPipeInputStream@56afbace
at java.base@17/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:270)
at java.base@17/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:313)
at java.base@17/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
- locked java.io.InputStreamReader@19565b5
...

[jukzi]

unnecessarily expensive to do for each and every unit test.

As far as i understand the job is only scheduled once, but each tests complains about it is still running

[jukzi]

in I20240914-1800 https://download.eclipse.org/eclipse/downloads/drops4/I20240914-1800/testresults/ep434I-unit-mac64-java17_macosx.cocoa.x86_64_17/org.eclipse.debug.tests.AutomatedSuite.txt
the dumps are

java.lang.RuntimeException: Some job is still running or waiting to run: 
'AutoRegisterSchemeHandlersJob(19)'/org.eclipse.urischeme.AutoRegisterSchemeHandlersJob
thread info: "Worker-2: AutoRegisterSchemeHandlersJob" prio=5 Id=45 RUNNABLE
	at java.base@17/java.io.FileInputStream.readBytes(Native Method)
	at java.base@17/java.io.FileInputStream.read(FileInputStream.java:276)
	at java.base@17/java.io.BufferedInputStream.read1(BufferedInputStream.java:282)
	at java.base@17/java.io.BufferedInputStream.read(BufferedInputStream.java:343)
	-  locked java.lang.ProcessImpl$ProcessPipeInputStream@2e2a2b07
	at java.base@17/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:270)
	at java.base@17/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:313)
	at java.base@17/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
	-  locked java.io.InputStreamReader@3c00da24
	at java.base@17/java.io.InputStreamReader.read(InputStreamReader.java:177)
	...

the stack is not long enough to see where that job hangs - but probably during reading output of some lsregister os command

[BeckerWdf]

I wonder if we could detect that we are running unit tests and not run the job in that case.

How could we detect his?

Additionally, we should probably also not run it in case of Platform.inDevelopmentMode().

That's a good idea.

[jukzi]

https://download.eclipse.org/eclipse/downloads/drops4/I20240919-1840/testresults/html/org.eclipse.debug.tests_ep434I-unit-macM1-java17_macosx.cocoa.aarch64_17.html does not show such as fails anymore.
however the logfile
https://download.eclipse.org/eclipse/downloads/drops4/I20240919-1840/testresults/ep434I-unit-macM1-java17_macosx.cocoa.aarch64_17/org.eclipse.debug.tests.AutomatedSuite.txt
still contains 1084 logs about

!STACK 0
java.lang.RuntimeException: Some job is still running or waiting to run: 
'AutoRegisterSchemeHandlersJob(19)'/org.eclipse.urischeme.AutoRegisterSchemeHandlersJob:RUNNING
thread info: "Worker-2: AutoRegisterSchemeHandlersJob" prio=5 Id=48 RUNNABLE
	at java.base@17/java.io.FileInputStream.readBytes(Native Method)
	at java.base@17/java.io.FileInputStream.read(FileInputStream.java:276)
	at java.base@17/java.io.BufferedInputStream.read1(BufferedInputStream.java:282)
	at java.base@17/java.io.BufferedInputStream.read(BufferedInputStream.java:343)
	-  locked java.lang.ProcessImpl$ProcessPipeInputStream@340f4723
	at java.base@17/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:270)
	at java.base@17/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:313)
	at java.base@17/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:188)
	-  locked java.io.InputStreamReader@136d1d58
	at java.base@17/java.io.InputStreamReader.read(InputStreamReader.java:177)
	...


	at org.eclipse.debug.tests.TestUtil.dumpRunningOrWaitingJobs(TestUtil.java:253)
	at org.eclipse.debug.tests.TestUtil.waitForJobs(TestUtil.java:235)
	at org.eclipse.debug.tests.TestUtil.waitForJobs(TestUtil.java:207)
	at org.eclipse.debug.tests.TestUtil.cleanUp(TestUtil.java:57)
	at org.eclipse.debug.tests.AbstractDebugTest.tearDown(AbstractDebugTest.java:64)

[sratz]

I wonder if we could detect that we are running unit tests and not run the job in that case.

How could we detect his?

#1453 (comment) would be an option

[BeckerWdf]

I wonder if we could detect that we are running unit tests and not run the job in that case.

Maybe we can set the "skipAutoRegistration" preference of the "org.eclipse.urischeme" during test execution.
See:

eclipse.platform.ui/bundles/org.eclipse.urischeme/src/org/eclipse/urischeme/AutoRegisterSchemeHandlersJob.java

Line 114 in 8df2017

return !(alreadyTriggered || Platform.getPreferencesService().getBoolean(UriSchemeExtensionReader.PLUGIN_ID,

[BeckerWdf]

Another option would be in the same way as the WindowsDefender check does it:
See: #1685

[BeckerWdf]

#1453 (comment) would be an option

Done in #2306