running java with LD_DEBUG-tracing
Baesken, Matthias
matthias.baesken at sap.com
Wed Dec 18 12:57:08 UTC 2019
Hi David, thanks for clarification .
Guess we can just remove the __ now and avoid one lookup.
I'll open a bug for this .
Best regards, Matthias
> On 18/12/2019 10:43 pm, David Holmes wrote:
> > On 18/12/2019 7:43 pm, Baesken, Matthias wrote:
> >> Hello, I recently worked a bit with the "verbose debugging
> >> information" output about operations of the dynamic linker (to
> >> sort out some lib loading issues) .
> >> See
> >>
> >> https://docs.oracle.com/cd/E19683-01/816-1386/chapter3-33/index.html
> >> http://man7.org/linux/man-pages/man8/ld.so.8.html
> >>
> >> about the LD_DEBUG flag.
> >>
> >>
> >> By chance I noticed the following output when running a trivial Java
> >> program :
> >>
> >> LD_DEBUG=libs /linuxx86_64/output-jdk-
> test/images/jdk/bin/java Test
> >> . . .
> >> 12241:
> >> 12241:
> >> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol
> >> lookup error: undefined symbol:
> >> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal)
> >> 12241:
> >>
> >> What is wrong with
> >> "Java_jdk_internal_reflect_Reflection_getCallerClass" ?
> >> Does the error message occur because of the naming
> >> Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added
> >> "__" at the end of the method (Reflection.c) ?
> >
> > That definitely looks like an error in the C source to me. The ending
> > "__" should not be there. How is this working ??
>
> Ah! It is a remnant of when there were overloads of getCallerClass. The
> "__" should be followed by the signature - which is empty in this case.
> So IIRC the lookup will first try to use the short name (without the
> trailing "__") which will fail, then it will use the long name which
> will succeed.
>
> It should be fixed so we don't waste time doing two lookups.
>
> David
>
> >
> > David
> >
> >>
> >>
> >> Best regards, Matthias
> >>
> >>
More information about the core-libs-dev
mailing list