RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624

Yasumasa Suenaga suenaga at oss.nttdata.com
Mon Mar 16 06:36:28 UTC 2020


Hi David,

Thank you for testing it.

I updated webrev to avoid bailout to Java frame when DWARF has language personality routine or LSDA.
Could you try it?

   http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.01/

It works well on my Fedora 31 and Oracle Linux 7.7 .
I've pushed it to submit repo.

Diff from webrev.00 is here:
   http://hg.openjdk.java.net/jdk/submit/rev/6f11cd275652


Thanks,

Yasumasa


On 2020/03/16 13:12, David Holmes wrote:
> Correction ...
> 
> On 16/03/2020 12:53 pm, David Holmes wrote:
>> On 16/03/2020 12:17 pm, David Holmes wrote:
>>> Hi Yasumasa,
>>>
>>> I can't review this as I know nothing about the code, but I'm putting the patch through our internal testing.
>>
>> Sorry but the crashes still exist:
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x00007fcdd403894e, pid=16948, tid=16949
>> #
>> # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-03-16-0214474.david.holmes.jdk-dev)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-03-16-0214474.david.holmes.jdk-dev, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
>> # Problematic frame:
>> # C  [libsaproc.so+0x494e]  DwarfParser::process_dwarf(unsigned long)+0x4e
>>
>> in fact they seem worse as the test seems to always crash now.
> 
> Not worse - sorry. I see 6 failures out of 119 runs of the test in linux-x64. I don't see a pattern as to where it fails versus passes.
> 
> It doesn't fail for me locally.
> 
> David
> 
>> David
>>
>>> David
>>>
>>> On 14/03/2020 11:35 am, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> Please review this change:
>>>>
>>>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8240956
>>>>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.00/
>>>>
>>>> JDK-8234624 introduced DWARF parser in SA for unwinding native frames in jstack mixed mode.
>>>> However some error has seen intermittently after that.
>>>>
>>>> I investigated the cause of this, I found two concerns:
>>>>
>>>>    A: lack of buffer (.eh_frame section data) range check
>>>>    B: Language personality routine and Language Specific Data Area (LSDA) are not considered
>>>>
>>>> I addd range check for .eh_frame processing, and ignore personality routine and LSDA in this webrev.
>>>> Also I added bailout code if DWARF processing is failed due to these concerns.
>>>>
>>>> This change has passed all tests on submit repo (mach5-one-ysuenaga-JDK-8240956-20200313-1518-9434671),
>>>> also I tested it on my Fedora 31 box and Oracle Linux 7.7 container.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa


More information about the serviceability-dev mailing list