RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing

David Holmes david.holmes at oracle.com
Wed Dec 18 22:02:30 UTC 2019


Hi Matthias,

Looks good. Thanks for fixing and finding. :)

David

On 19/12/2019 12:33 am, Baesken, Matthias wrote:
> Hello  David,
> Here is a change  that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass  -
> 
> With this change, I checked the output of   LD_DEBUG=libs     java Test   ,  and the error I observed before is gone .
> 
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8236183
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8236183.0/
> 
> 
> Thanks, Matthias
> 
> 
>>>>
>>>> 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
> 


More information about the core-libs-dev mailing list