Current plan is to protect the library loading (which is only used on
VMWare and only to later include additional info in HotSpot error
reports if they happen) with the already existing switch
-XX:ExtensiveErrorReports (default false). The good thing is, that then
it will no longer happen by default, the bad is, that an error report
switch would have a side effect that can lead to errors even without any
error report happening.
Regards,
Rainer
Am 30.07.2019 um 09:48 schrieb Rainer Jung:
The HotSpot runtime team is investigating it. It was a surprise for them.
New ticket opened by David Holmes:
https://bugs.openjdk.java.net/browse/JDK-8228764
Mail thread starts at:
https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-July/035431.html
Original implementation ticket:
https://bugs.openjdk.java.net/browse/JDK-8222720
Backport to OpenJDK 11 (for 11.0.5, not yet released):
https://bugs.openjdk.java.net/browse/JDK-8226873
Regards,
Rainer
Am 29.07.2019 um 23:45 schrieb Rainer Jung:
OpenJDK 13/14 introduced change fb5b3981eac:
8222720: Provide extended VMWare/vSphere virtualization related info
in the hs_error file on linux/windows x86_64
On SLES 12 (maybe also other Linuxes) the impl loads
/usr/lib64/libguestlib.so.0 already during JVM startup. That library
depends on /usr/lib64/libvmtools.so.0, which in turn depends on a lot
of other libraries:
NEEDED libdnet.so.1
NEEDED libglib-2.0.so.0
NEEDED libicui18n.so.52.1
NEEDED libicuuc.so.52.1
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libssl.so.1.0.0
NEEDED libcrypto.so.1.0.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
NEEDED libgcc_s.so.1
When building tcnative against OpenSSL 1.0.x, the JVM has already
loaded OpenSSL 1.0 system libs via the above dependency and will not
load our tcnative dependency. This lead to a subtle failure in my case:
/usr/local/jdk13/bin/java: symbol lookup error:
/path/to/lib/libtcnative-1.so.0.2.23: undefined symbol:
SSL_COMP_free_compression_methods
Even worse could be using OpenSSL 1.1.x for tcnative. Then the JVM
would load the 1.0.x version, tcnative would load the 1.1.x version
but symbols that exist in both would be resolved by the runtime linker
in the older version, because it was loaded first (default symbol
search order). All of that can be worked around by non-default linking
tricks, but I wanted to point out this new behavior.
I have written to hotspot-runtime-...@openjdk.java.net about these new
dependencies and potential problems.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
