JDK-8309549 : com/sun/tools/attach/warnings/DynamicLoadWarningTest.java fails on AIX
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: aix
  • CPU: ppc
  • Submitted: 2023-06-06
  • Updated: 2023-07-04
  • Resolved: 2023-06-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22
21Fixed 22 b02Fixed
Related Reports
Relates :  
JDK-8310191 - com/sun/tools/attach/warnings/DynamicLoadWarningTest.java second failure on AIX
Relates :  
JDK-8307478 - Implementation of Prepare to Restrict The Dynamic Loading of Agents
Description
After push of JDK-8307478 , the following test started to fail on AIX :
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java ; it always fails on AIX with the output :

----------System.err:(294/28579)----------
STARTED DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
SUCCESSFUL DynamicLoadWarningTest::testLoadJavaAgent 'testLoadJavaAgent()'
STARTED DynamicLoadWarningTest::testLoadOneJvmtiAgent '[1] DynamicLoadWarningTest$$Lambda/0x000000040020bd88@600d90bb'
org.opentest4j.AssertionFailedError: expected: <1> but was: <2>
at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
at DynamicLoadWarningTest$AppRunner.stderrShouldContain(DynamicLoadWarningTest.java:298)
at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:125)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21/pull/44 Date: 2023-06-21 07:29:03 +0000
21-06-2023
I created JDK-8310191 to address the second issue.
16-06-2023
[~mbaesken] The 4th test in testLoadOneJvmtiAgent also loads the same agent twice, the first via the command line, the second into the running VM, a warning is not expected as the agent library is previously loaded. So same issue as JDK-8309549, needs to be skipped on AIX.
12-06-2023
After the issue above has been fixed we unfortunately still get this new error : java.lang.RuntimeException: 'WARNING: A JVM TI agent has been loaded dynamically' found in stderr at jdk.test.lib.process.OutputAnalyzer.stderrShouldNotContain(OutputAnalyzer.java:320) at DynamicLoadWarningTest$AppRunner.stderrShouldNotContain(DynamicLoadWarningTest.java:308) at DynamicLoadWarningTest.testLoadOneJvmtiAgent(DynamicLoadWarningTest.java:138) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) And indeed 'WARNING: A JVM TI agent has been loaded dynamically' can be found in the log on AIX, so there is still something wrong .
12-06-2023
Changeset: 4d66d977 Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2023-06-12 07:07:38 +0000 URL: https://git.openjdk.org/jdk/commit/4d66d977450e083214da3dba6ad4ed851c6c1cb4
12-06-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/14393 Date: 2023-06-09 13:39:26 +0000
09-06-2023
[~mbaesken] It would be great if you have time to take this one. Skipping the duplicate warning test should be as simple as ``` --- a/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java +++ b/test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java @@ -119,10 +119,13 @@ class DynamicLoadWarningTest { test().whenRunning(loadJvmtiAgent1) .stderrShouldContain(JVMTI_AGENT_WARNING); - // dynamically load loadJvmtiAgent1 twice, should be one warning - test().whenRunning(loadJvmtiAgent1) - .whenRunning(loadJvmtiAgent1) - .stderrShouldContain(JVMTI_AGENT_WARNING, 1); + // dynamically load loadJvmtiAgent1 twice, should be one warning on platforms + // that can detect if an agent library was previously loaded + if (!Platform.isAix()) { + test().whenRunning(loadJvmtiAgent1) + .whenRunning(loadJvmtiAgent1) + .stderrShouldContain(JVMTI_AGENT_WARNING, 1); + } ``` but I have no way to test it.
09-06-2023
Hi [~alanb], >The spec doesn't require that warnings be de-duplicated so maybe it can be tolerated on AIX, in which case one of the tests in testLoadOneJvmtiAgent should be >skipped when Platform.isAix() is true. WDYT? I think the skipping you suggested makes sense - do you want to post a PR or should I test/try it and post one ?
09-06-2023
[~mbaesken] Thanks for the links. The check to see if an agent library was previously loaded assumes the the same handle is returned if dlopen'ed a second or subsequent time. It would be possible to check canonical path or compare st_dev/st_ino but it would add complexity. A simple string compare of agent name or os_lib_path isn't sufficient in some cases, esp. when the path is relative. The spec doesn't require that warnings be de-duplicated so maybe it can be tolerated on AIX, in which case one of the tests in testLoadOneJvmtiAgent should be skipped when Platform.isAix() is true. WDYT?
08-06-2023
ILW=MMH=P3
07-06-2023
This is what I find in the manpage of AIX 7.2 or 7.3 : https://www.ibm.com/docs/en/aix/7.2?topic=d-dlopen-subroutine https://www.ibm.com/docs/en/aix/7.3?topic=d-dlopen-subroutine "If the module is already loaded, it is not loaded again, but a new, unique value will be returned by the dlopen subroutine." Sounds different to what Linux documents in the manpage: https://man7.org/linux/man-pages/man3/dlopen.3.html "If the same shared object is opened again with dlopen(), the same object handle is returned." Should I check for more details with our local AIX experts?
07-06-2023
One of the tests in testLoadOneJvmtiAgent is to load the same agent twice, it expects one warning. In the output we see: WARNING: A JVM TI agent has been loaded dynamically (/priv/testr/outputdir/grmpf/testdata/jtreg/jtreg_test_21/test/jdk/jtreg/native/libJvmtiAgent1.so) WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning WARNING: Dynamic loading of agents will be disallowed by default in a future release WARNING: A JVM TI agent has been loaded dynamically (/priv/testr/outputdir/grmpf/testdata/jtreg/jtreg_test_21/test/jdk/jtreg/native/libJvmtiAgent1.so) WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning WARNING: Dynamic loading of agents will be disallowed by default in a future release so we've got two warnings. JvmtiAgentList::is_dynamic_lib_loaded is the function that is called to check if an agent library was previously loaded. It's looking at os_lib, the handle returned by dlopen. The man pages for dlopen on Linux and macOS are clear that a second call to dlopen with the same path returns the same handle. I suspend the issue is that dlopen on AIX working differently and that a different handle is being returned. Is that something you could check?
07-06-2023
I attached a slightly modified jtr file of the failing test.
07-06-2023
com/sun/tools/attach/warnings/DynamicLoadWarningTest.java is a new test added by JDK-8307478 (implementation of JEP 451). The check for a duplicate agent library appears to be problematic on AIX, maybe dlopen behaves differently on that platform? [~mbaesken] Is there any way that you could attach a sample .jtr file, maybe editing it to avoid revealing things about the environment that you don't want to reveal?
06-06-2023