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

[Chris Plummer]

On 3/15/20 11:51 PM, Yasumasa Suenaga wrote:
> On 2020/03/16 15:43, Chris Plummer wrote:
>> BTW, if you submit it to the submit repo, we can then go and run 
>> additional internal tests (and even more builds) using that job.
>
> I've pushed the change to submit repo, but I've not yet received the 
> result.
> I will share you when I get job ID.
I see it, but I'm off to bed and am not sure what David was running, so 
I'll let him take a stab at it.

Chris
>
> Yasumasa
>
>> Chris
>>
>> On 3/15/20 11:36 PM, Yasumasa Suenaga wrote:
>>> 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
>>
>>