You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2019/07/29 21:45:36 UTC
tcnative and JDK13/14
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-dev@openjdk.java.net about these new
dependencies and potential problems.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tcnative and JDK13/14
Posted by Rainer Jung <ra...@kippdata.de>.
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-dev@openjdk.java.net about these new
>> dependencies and potential problems.
>>
>> Regards,
>>
>> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: tcnative and JDK13/14
Posted by Rainer Jung <ra...@kippdata.de>.
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-dev@openjdk.java.net about these new
> dependencies and potential problems.
>
> Regards,
>
> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org