Running java -Xaot: causes abort

[pshipton]

If you run java -Xaot: it causes an abort. Normally you'd get diagnostic files. If running with -Xdump:none you don't get the OpenJ9 diagnostics, but still get a core file.

java -Xdump:none -Xaot:
JVMJ9VM015W Initialization error for library j9jit29(11): no arguments for -Xaot:
Aborted (core dumped)

This is related to the testCompilerArguments functional test. The test doesn't fail, but does produce a core file, and may timeout.

22:54:13  Testing: Check empty -Xaot:
22:54:13  Test start time: 2024/11/15 03:35:38 Coordinated Universal Time
22:54:13  Running command: "/home/jenkins/workspace/Test_openjdk21_j9_sanity.functional_ppc64_aix_Nightly_testList_1/jdkbinary/j2sdk-image/bin/java"   -Xdump:none -Xaot: -version
22:54:13  Time spent starting: 5 milliseconds
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] destroy test process after timeout***
22:54:45  Time spent executing: 30038 milliseconds
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] java.lang.IllegalThreadStateException: process hasn't exited***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at java.base/java.lang.ProcessImpl.exitValue(ProcessImpl.java:452)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at Test.run(Test.java:259)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at TestSuite.runTest(TestSuite.java:84)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at TestIterator.addTest(TestIterator.java:84)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at TestConfigParser$TestConfigDocumentHandler.xmlEndElement(TestConfigParser.java:309)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at com.oti.j9.exclude.XMLParser._scan_element_close(XMLParser.java:370)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at com.oti.j9.exclude.XMLParser._scan_element_or_instruction(XMLParser.java:391)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at com.oti.j9.exclude.XMLParser.parseXML(XMLParser.java:442)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at com.oti.j9.exclude.XMLParser.parse(XMLParser.java:470)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at com.oti.j9.exclude.XMLParser.parse(XMLParser.java:459)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at TestConfigParser.runTests(TestConfigParser.java:78)***
22:54:45  ***[TEST INFO 2024/11/15 03:36:08] 	at MainTester.main(MainTester.java:106)***

[pshipton]

@hzongaro is the abort intentional?

[github-actions]

Issue Number: 20601
Status: Open
Recommended Components: comp:test, comp:gc, comp:vm
Recommended Assignees: pshipton, jasonfengj9, keithc-ca

[hzongaro]

@hzongaro is the abort intentional?

Sorry - I missed this issue when you first reported it.

No, it doesn't look like the abort was intentional. It looks like a null pointer in trvm is being dereferenced in DLLMain.cpp.

If I run with -Xjit:, when we come back to this method with stage equal to INTERPRETER_SHUTDOWN, vm->jitConfig is null, so there's no problem. But with -Xaot:, vm->jitConfig is non-null, but trvm is null, which results in a crash.

@dsouzai, may I ask you to take a look at this crash? I'll move this out to the 0.51 release.

[dsouzai]

Because of

openj9/runtime/compiler/control/DLLMain.cpp

Lines 436 to 452 in 5329b1b

	/* do initializations for -Xjit options */
	if (isJIT && argIndexXjit >= 0)
	{
	IDATA rc = initializeCompilerArgs(vm, loadInfo, vm->vmArgsArray, argIndexXjit, &xjitCommandLineOptions, true, mergeCompilerOptions);
	if (rc)
	return rc;
	}
	codert_onload(vm);
	/* do initializations for -Xaot options */
	if (isAOT && argIndexXaot >= 0)
	{
	IDATA rc = initializeCompilerArgs(vm, loadInfo, vm->vmArgsArray, argIndexXaot, &xaotCommandLineOptions, false, mergeCompilerOptions);
	if (rc)
	return rc;
	}

we initialize the -Xjit: args, then set vm->jitConfig (in codert_onload) and then initialize the -Xaot: args. So, when the JIT args are empty we happen to bypass the code guarded by vm->jitConfig. I have no idea why we call codert_onload between the two initializations, but it wouldn't surprise me if there happened to be some convoluted reason for it.

I think a fix should be pretty straightforward, we just need to also check if trvm is NULL; when we call TR_J9VMBase::get with a NULL vmThread argument, it effectively returns jitConfig->compilationInfo (despite the name this is not the compilationinfo but the frontend...), which doesn't get set until onLoadInternal, which only happens if we managed to successfully initialize the compiler args.