* Assertion when loading shared object with unmet version dependencies
@ 2020-02-14 23:16 Marc Streckfuß
2020-02-15 9:54 ` Florian Weimer
2020-02-15 12:58 ` Florian Weimer
0 siblings, 2 replies; 6+ messages in thread
From: Marc Streckfuß @ 2020-02-14 23:16 UTC (permalink / raw)
To: libc-help
Hello all!
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
So, the problem is: With OpenJDK 11, they removed the source maps, so the
symbol SUNWprivate_1.1 which lwjgl2's verneed depends on isn't emitted
anymore.
Furthermore it depends on whether building openJDK with Debian, where the
linker still emits GLIBC_2_2_5 symbols, so versym and verneed still exist
[and verdef doesn't] or building with Ubuntu, where no version table
doesn't exist at all.
So when building with Debian, I can load lwjgl2, even though the version
dependency cannot be resolved, the symbol is just loaded.
When building on Ubuntu, where no version table exists at all, the
following assertion crashes the application.
In case you want to read the whole story, the following are our tracking
bugs:
https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1838740
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003865.html
btw: Even when building on Ubuntu with Debians glibc, I fail to make it
emit the version tables.
Thanks in Advance!
Marc Streckfuß
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Assertion when loading shared object with unmet version dependencies
2020-02-14 23:16 Assertion when loading shared object with unmet version dependencies Marc Streckfuß
@ 2020-02-15 9:54 ` Florian Weimer
2020-02-15 12:58 ` Florian Weimer
1 sibling, 0 replies; 6+ messages in thread
From: Florian Weimer @ 2020-02-15 9:54 UTC (permalink / raw)
To: Marc Streckfuß; +Cc: libc-help
* Marc Streckfuß:
> In case you want to read the whole story, the following are our tracking
> bugs:
> https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1838740
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003865.html
I replied on jdk-dev:
<https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003910.html>
Let's continue the discussion there.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Assertion when loading shared object with unmet version dependencies
2020-02-14 23:16 Assertion when loading shared object with unmet version dependencies Marc Streckfuß
2020-02-15 9:54 ` Florian Weimer
@ 2020-02-15 12:58 ` Florian Weimer
2020-02-15 13:25 ` Marc Streckfuß
[not found] ` <-8369114514235633150@unknownmsgid>
1 sibling, 2 replies; 6+ messages in thread
From: Florian Weimer @ 2020-02-15 12:58 UTC (permalink / raw)
To: Marc Streckfuß; +Cc: libc-help
* 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Assertion when loading shared object with unmet version dependencies
2020-02-15 12:58 ` Florian Weimer
@ 2020-02-15 13:25 ` Marc Streckfuß
[not found] ` <-8369114514235633150@unknownmsgid>
1 sibling, 0 replies; 6+ messages in thread
From: Marc Streckfuß @ 2020-02-15 13:25 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-help
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Assertion when loading shared object with unmet version dependencies
[not found] ` <-8369114514235633150@unknownmsgid>
@ 2020-02-24 15:21 ` Marc Streckfuß
2020-02-24 16:26 ` Florian Weimer
0 siblings, 1 reply; 6+ messages in thread
From: Marc Streckfuß @ 2020-02-24 15:21 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-help
Hey, sorry for the nagging but did you make any progress on that?
Or can you guide me so I can make any progress on this?
Cheers,
Marc
Am Sa., 15. Feb. 2020 um 14:25 Uhr schrieb Marc Streckfuß <
marc.streckfuss@gmail.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.
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Assertion when loading shared object with unmet version dependencies
2020-02-24 15:21 ` Marc Streckfuß
@ 2020-02-24 16:26 ` Florian Weimer
0 siblings, 0 replies; 6+ messages in thread
From: Florian Weimer @ 2020-02-24 16:26 UTC (permalink / raw)
To: Marc Streckfuß; +Cc: libc-help
* Marc Streckfuß:
> Hey, sorry for the nagging but did you make any progress on that?
> Or can you guide me so I can make any progress on this?
It would help if we had all the binaries unpacked, along with a shell
command that triggers the assertion. I have not had time yet to chase
the downloads.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-24 16:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 23:16 Assertion when loading shared object with unmet version dependencies Marc Streckfuß
2020-02-15 9:54 ` Florian Weimer
2020-02-15 12:58 ` Florian Weimer
2020-02-15 13:25 ` Marc Streckfuß
[not found] ` <-8369114514235633150@unknownmsgid>
2020-02-24 15:21 ` Marc Streckfuß
2020-02-24 16:26 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).