On Fri, May 10, 2019 at 8:37 PM Waldek Kozaczuk <[email protected]>
wrote:

>
>
> On Sunday, April 14, 2019 at 8:16:04 PM UTC-4, Waldek Kozaczuk wrote:
>>
>> > libjli.so is needed by jre/lib/amd64/libinstrument.so. On my host
>> (Fedora 29),
>> >
>> >
>> > $ ldd /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/libinstrument.so
>> >         linux-vdso.so.1 (0x00007ffec512e000)
>> >         libz.so.1 => /lib64/libz.so.1 (0x00007fcd91ac0000)
>> >         libjli.so =>
>> /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/jli/libjli.so
>> (0x00007fcd91aae000)
>> >         libdl.so.2 => /lib64/libdl.so.2 (0x00007fcd91aa8000)
>> >         libc.so.6 => /lib64/libc.so.6 (0x00007fcd918e2000)
>> >         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcd918c0000)
>> >         /lib64/ld-linux-x86-64.so.2 (0x00007fcd91b28000)
>> >
>> >
>> >
>> > How did it find the pathname of libjli.so? Well,
>> >
>> >
>> >
>> > $ readelf -a
>> /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/libinstrument.so
>> > ...
>> >  0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
>> >  0x0000000000000001 (NEEDED)             Shared library: [libjli.so]
>> >  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>> >  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>> >  0x000000000000000e (SONAME)             Library soname:
>> [libinstrument.so]
>> >  0x000000000000000f (RPATH)              Library rpath:
>> [$ORIGIN:$ORIGIN/jli]
>> >
>> >
>> >
>> > This RPATH asks when loading
>> /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/libinstrument.so and
>> searching for "libjli.so" to also search for it in $ORIGIN/jli, i.e.,
>> /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/jli. Where it indeed is.
>> >
>> >
>> > And we do have proper handling of DT_RPATH in core/elf.cc.
>> >
>> >
>> > So either we have a bug in that RPATH handling that wasn't apparent to
>> me now when I reviewed the code (and to Avi Kivity when he wrote it), or
>> there's a different problem. Maybe me installed libjli.so at the wrong
>> tree? Maybe if you add printouts to core/elf.cc's handling of DT_RPATH you
>> can see more clearly what's the bug.
>> I will try to figure it out. Hopefully something simple.
>>
> It has to do with the fact that I am executing is a symlink to real
> executable:
> /java ->
> /usr/lib/jvm/jdk-zulu11.31.11-ca-jdk11.0.3-linux_x64-java-base/bin/java
>
> So if I execute this:
> /scripts/run.py -e 
> '/usr/lib/jvm/jdk-zulu11.31.11-ca-jdk11.0.3-linux_x64-java-base/bin/java
> --version'
> it works.
>
> If I execute this:
> /scripts/run.py -e '/java --version'
> it fails as I described in my original error.
>

Excellent detective work.  I opened
https://github.com/cloudius-systems/osv/issues/1039 on this.
I outlined the problem you discovered, and the very simple fix:

object::load_needed does today:
        boost::replace_all(rpath_str, "$ORIGIN", dirname(_pathname));

Instead of using "_pathname" here as-is, we need to first try readlink() on
_pathname and use the result if it is indeed a link, instead of _pathname.
But actually, we need to do this in a loop (we can have a link to a link to
a link!). But with a limit to avoid infinite iterations.
Should be very easy to fix. I would be happy if you send a patch for this
because you already have the setup to test it.


> Here is the dynamic section of java:
> Dynamic section at offset 0x1018 contains 30 entries:
>   Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
>  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
>  *0x0000000000000001 (NEEDED)             Shared library: [libjli.so]*
>  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>  *0x000000000000000f (RPATH)              Library rpath:
> [$ORIGIN/../lib/jli:$ORIGIN/../lib]*
>  ...
>
> and this part of the host file system (which is the same as on OSv FS):
>
> /usr/lib/jvm/jdk-zulu11.31.11-ca-jdk11.0.3-linux_x64-java-base/lib/jli/libjli.so
> /usr/lib/jvm/jdk-zulu11.31.11-ca-jdk11.0.3-linux_x64-java-base/bin/java
> /java ->
> /usr/lib/jvm/jdk-zulu11.31.11-ca-jdk11.0.3-linux_x64-java-base/bin/java
>
> It works on Linux so I guess there is a way to fix it.
>
> >
>> >
>> >
>> >
>> > there is a bug that silently ignores the fact that shared file has not
>> been loaded and ends up OSv report this:
>> > For historic reasons, OSv prints missing DT_NEEDED messages with
>> debug():
>> >
>> >
>> >             debug("could not load %s\n", lib);
>> >
>> >
>> >  This means that unless you run with --verbose, you'll never see these
>> messages...
>> >
>> > Hiding these messages was convenient in the past, and sometimes still
>> is (see https://github.com/cloudius-systems/osv/issues/601) but maybe it
>> makes sense to convert this message to a debug_always(), so it is always
>> shown?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java: failed looking up
>> symbol JLI_Launch
>> >
>> >
>> > [backtrace]
>> > 0x000000000035cb8d <elf::object::symbol(unsigned int, bool)+1325>
>> > 0x000000000035cc4f <elf::object::resolve_pltgot(unsigned int)+127>
>> > 0x000000000035ce29 <elf_resolve_pltgot+57>
>> > 0x00000000003a2d1f <???+3812639>
>> > 0x00002000001ffe9f <???+2096799>
>> > 0x000000000042e97c <osv::application::run_main()+60>
>> > 0x000000000042eaae <__libc_start_main+46>
>> > 0x00001000000060c9 <???+24777>
>> >
>> >
>> > I also ran more complicated examples like vertx REST service one and it
>> worked perfectly.
>> >
>> >
>> > Waldek
>> >
>> >
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> Groups "OSv Development" group.
>> >
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to [email protected].
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/d768b6be-ffa2-4391-abeb-6b558493e299%40googlegroups.com
> <https://groups.google.com/d/msgid/osv-dev/d768b6be-ffa2-4391-abeb-6b558493e299%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osv-dev/CANEVyjuvvKipskHXxgYgujkd%3Dp-dw4SEFdSVoWT%2Boma3v3B8sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to