Re: Assertion when loading shared object with unmet version dependencies

[Marc Streckfuß <marc dot streckfuss at gmail dot com>]

Sure:

This is the Ubuntu Build:
http://security.ubuntu.com/ubuntu/pool/main/o/openjdk-lts/openjdk-11-jre-headless_11.0.6+10-1ubuntu1~18.04.1_amd64.deb

This is the Debian Build:
http://ftp.de.debian.org/debian/pool/main/o/openjdk-11/openjdk-11-jre-headless_11.0.6+10-1~deb10u1_amd64.deb

You can extract both using "dpkg-deb -R file.deb tmp/". If you are
unable to use that tool, I can upload/attach to this e-mail(?) the files.
You are looking for libs/libjawt.so, which is merely a gate for the real
libawt.so (FWIW).

Now the difference is that Ubuntu has "optimized" the .so and removed
the versioned dependency on _cxa_finalize and thus discarded all sections.

https://repo1.maven.org/maven2/org/lwjgl/lwjgl/lwjgl-platform/2.9.3/lwjgl-platform-2.9.3-natives-linux.jar
This is the file triggering the condition, when the JDK tries to load
the contained .so (you can unzip it), this so tries to load libjawt.
Oh and I've only tested this for x64.

Also note that with Debian there is no failure. Either the library has a
fallback or loading works without that versioning.

Am 15.02.20 um 13:57 schrieb Florian Weimer:
> * Marc Streckfuß:
>
>> I am currently debugging a strange problem where loading a native library
>> stops working depending on the build environment used to build openJDK.
>>
>> Basically when loading the lwjgl2.so, it fails at the following assertion:
>> https://github.com/lattera/glibc/blob/master/elf/dl-lookup.c#L111
> I missed the part where this isn't a load failure, but an assertion
> failure.  Would you please put the object files which trigger this
> somewhere, so that we can figure out the exact triggering conditions?
>
> This should really result in a dlopen failure, not a failing assert.