JDK23 SharedClasses.SCM01.MultiThreadMultiCL_1_FAILED NumberFormatException: For input string: "-Xdump:system+java:events=throw,filter=java/lang/NullPointerException#java/lang/invoke/BruteArgumentMoverHandle.permuteArguments*" #19439
Comments
|
4/5 machines failed 5/10, the other failed 3/10. @llxia pls have someone from test take the first look since it's LoaderSlaveMultiThreadMultiCL.main() trying to parse an integer. It expects args[1] to be an int, but for some reason it's a JVM argument. |
|
Last passing build First failing build, this is a personal build. JasonFengJ9/openj9@4998aab...a5a74e6 - SHA a5a74e6b325 no longer available First non-personal build failure 4998aab...0a576e3 |
|
Ah interesting, the NumberFormatException isn't the cause of the failure, this occurs in passing runs. |
|
According to the test code, the NumberFormatException will be caught. And the test will move on. Details: |
|
I do not think this PR - Add new debug options for sc mt test is valid: adoptium/openj9-systemtest@df3753a. Instead of adding @annaibm could you give it a try? Thanks |
|
Actual failure Looking at the core for |
|
@keithc-ca fyi this is why #19417 made a difference, it avoided loading Blocker early in bootstrap, which is no longer loaded elsewhere. |
|
@tajila pls assign, the deadlock condition needs to be fixed. |
|
There is no core file for the reported failure, but the earlier failure on a personal build has one and shows we have a deadlock condition. Although the java code was modified after the personal build by #19417 to avoid loading I don't have native stack traces, but this could be what's going on. findClassOrNull() calls internalFindClassString(), calls internalFindClassInModule(), JVM_DefineModule() locks classLoaderModuleAndLocationMutex at the start of the function java11vmi.c : 768 |
|
@llxia @annaibm whatever problem we were trying to get diagnostics for via adoptium/openj9-systemtest@df3753a seems obsolete now. I think we should remove the change rather than fix it. Adding |
If its easily reproduceable I can make a patch to address that case. |
It failed 23/50 in the grinder. |
- Remove `-Xdump:system+java:events=throw,filter=java/lang/NullPointerException#java/lang/invoke/BruteArgumentMoverHandle.permuteArguments*` from args\ related: eclipse-openj9/openj9#19439 Signed-off-by: Anna Babu Palathingal <[email protected]>
- Remove `-Xdump:system+java:events=throw,filter=java/lang/NullPointerException#java/lang/invoke/BruteArgumentMoverHandle.permuteArguments*` from args\ related: eclipse-openj9/openj9#19439 Signed-off-by: Anna Babu Palathingal <[email protected]>
- Remove `-Xdump:system+java:events=throw,filter=java/lang/NullPointerException#java/lang/invoke/BruteArgumentMoverHandle.permuteArguments*` from args\ related: eclipse-openj9/openj9#19439 Signed-off-by: Anna Babu Palathingal <[email protected]>
Thread 1 creates java.base: - acquires module (classLoaderModuleAndLocationMutex) mutex - acquires class mutex (classTableMutex) to update all bootstrap classes Thread 2 loads a class - aquires class mutex - acquire module mutex to search for class location There is a scenario where Thread 1 acquires module mutex, then thread 2 acquires class mutex. Thread 1 cannot complete creating java.base because it needs the class mutex and Thread 2 cannot complete class loading because it needs the module mutex. Proposed solution is for Thread 1 to acquire the class mutex first if it is known that it will be needed. Related: eclipse-openj9#19439 Signed-off-by: tajila <[email protected]>
|
A grinder with test build https://hyc-runtimes-jenkins.swg-devops.com/job/Grinder/40386 (rerun) |
|
just for the record, re #19439 (comment), -Xdump options is removed. See adoptium/openj9-systemtest#153 |
|
Passed 50/50 with the #19458 changes |
|
Closing this as changes are in |
Thread 1 creates java.base: - acquires module (classLoaderModuleAndLocationMutex) mutex - acquires class mutex (classTableMutex) to update all bootstrap classes Thread 2 loads a class - aquires class mutex - acquire module mutex to search for class location There is a scenario where Thread 1 acquires module mutex, then thread 2 acquires class mutex. Thread 1 cannot complete creating java.base because it needs the class mutex and Thread 2 cannot complete class loading because it needs the module mutex. Proposed solution is for Thread 1 to acquire the class mutex first if it is known that it will be needed. Related: eclipse-openj9#19439 Signed-off-by: tajila <[email protected]>
Failure link
From an internal build(
ubu22-aarch64-1):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x internal grinder - #19439 (comment)
The text was updated successfully, but these errors were encountered: