Community
Participate
Working Groups
Recent versions of IBM JDK for AIX are linked with -brtl, which enables runtime linking. The result is that no undefined symbols can exist at the time a shared library is loaded by dlopen(). The linked dependency graph of some of the libraries are circular, and we currently rely on having the dynamic linker patch this up when libraries are loaded at runtime. In particular, the runtime linker fails to load libtptpConfig.so because it has undefined references to libprocessControlUtil: JVMJ9TI003E Agent_OnLoad failed for library JPIBootLoader JVMJ9VM015W Initialization error for library j9jvmti24(-3): JVMJ9VM009E J9VMDllMain failed Could not create the Java virtual machine. dll libtptpAgentBase.so failed to load: rtld: 0712-001 Symbol modifyApplicationEnvironment was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol getEnvironmentStrings was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol freeEnvironmentStrings was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found. dll /opt/AC/lib/libtptpAgentBase.so failed to load: rtld: 0712-001 Symbol modifyApplicationEnvironment was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol getEnvironmentStrings was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found. rtld: 0712-001 Symbol freeEnvironmentStrings was referenced from module /opt/AC/lib/libtptpConfig.so(), but a runtime definition of the symbol was not found.
Created attachment 187977 [details] Patch It seems this can be solved by simply linking libtptpConfig with libprocessControlUtil. This records the undefined symbols as coming from libprocessControlUtil.so. The runtime linker is then able to load libprocessControlUtil and bind the symbols accordingly. This continues to work with JDKs that do not have runtime linking enabled. Patch attached.
I would like to request that the following defect be considered for PMC approval for 4.7.2. 1. Explain why you believe this is a stop-ship defect. How does the defect manifest itself, and how will users of TPTP / consuming products be affected if the defect is not fixed? Consuming products who want to support AIX will not be able to perform any profiling using recent IBM JDKs. 2. Is there a work-around? If so, why do you believe the work-around is insufficient? Only workaround is to utilize an alternate JDK. This is not sufficient because users can configure a JDK of their choosing. 3. Is this a regression or API breakage? Explain. Latent defect. In theory any JDK which was linked in this manner would encounter this problem. The seriousness is due to the fact that recent versions of the IBM JDK consumed by downstream products expose this problem. 4. Does this require new API? No. 5. Who performed the code review? Jon West 6. Is there a test case attached to the bugzilla record? n/a 7. What is the nature of the fix? What is the risk associated with this fix? Fix is a change to AIX-specific makefile. All other platforms are unchanged. Low-risk, not a code change. 8. Is this fix related to any standards that TPTP adheres to? If so, who has validated that the fix continues to adhere to the standard? Not applicable to any standards.
Requesting approval for TPTP 4.7.2.
Patch checked into HEAD. Resolving.
Reopening. The first patch introduces a build error because we build tptpConfig before processControlUtil. This was not noticed earlier as I had mistakenly thought the clean target removes .so files from the lib/ directory. The solution is to swap the order that tptpConfig and processControlUtil are built (i.e. build processControlUtil first). 'processControlUtil' does not depend on tptpConfig on any platform, so this works on the other Unix platforms. It has been tested with a thorough clean (removing .so files from lib/) on the following platforms: AIX (32- and 64-bit) Linux IA32 Solarisx86 (32- and 64-bit) The build script uses a zOS-specific build order, so it is unaffected. The remaining Linux variants also use the same build order as IA32 and so should have no trouble building. The Windows build system is entirely different and so is also unaffected.
Created attachment 188344 [details] Patch part2 Attached patch which swaps build order of tptpConfig and processControlUtil.
Jon, can you review this latest patch?
Re-resolving; the second patch is being handled through bug 336385.
Closing.
