RFR: 8240956: SEGV in DwarfParser::process_dwarf after JDK-8234624
Kevin Walls
kevin.walls at oracle.com
Fri Mar 27 07:42:16 UTC 2020
Great, thanks Yasumasa. Don't worry, the language is not just you -
it's often unclear in other places. 8-) Sorry maybe I should have said
you didn't need to resubmit the webrev for that, but a retest is nice.
Thanks
Kevin
On 27/03/2020 02:49, Yasumasa Suenaga wrote:
> All tests on submit repo has been passed.
> (mach5-one-ysuenaga-JDK-8240956-3-20200327-0003-9753265)
>
> Yasumasa
>
> On 2020/03/27 9:07, Yasumasa Suenaga wrote:
>> Thanks Kevin and Serguei! and sorry for my English...
>>
>> I uploaded new webrev:
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.05/
>>
>> Diff from webrev.04 is here:
>>
>> http://hg.openjdk.java.net/jdk/submit/rev/d5f400d70e94
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2020/03/27 2:53, serguei.spitsyn at oracle.com wrote:
>>> Hi Kevin,
>>>
>>> Nice catch with the name "lastFrame".
>>> I was also confused when reviewed this but did not come up with
>>> something better.
>>>
>>> Thanks,
>>> Serguei
>>>
>>> On 3/26/20 10:40, Kevin Walls wrote:
>>>> Hi Yasumasa,
>>>>
>>>> Oops, didn't catch this - I also had done some manual testing and
>>>> in mach5 but clearly not enough.
>>>>
>>>> Generally I think this looks good.
>>>>
>>>> "lastFrame" can mean last as in final, or last as in previous.
>>>> "last" is one of those annoying English words. Here it means final,
>>>> if we get an Exception during processDwarf, use this to flag that
>>>> we should return null from sender(). "finalFrame" would be clearer
>>>> to me, anything else probably gets more verbose than you wanted.
>>>>
>>>> Yes I like having the limit on the while loop in process_dwarf(),
>>>> always worried how sane the information is that we are parsing
>>>> through.
>>>>
>>>> Thanks!
>>>> Kevin
>>>>
>>>>
>>>> On 24/03/2020 23:47, Yasumasa Suenaga wrote:
>>>>> Thanks Serguei!
>>>>>
>>>>> I will push it when I get second reviewer.
>>>>>
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2020/03/25 1:39, serguei.spitsyn at oracle.com wrote:
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> I'm okay with this update.
>>>>>> My mach5 test run for this patch is passed.
>>>>>>
>>>>>> Thanks,
>>>>>> Serguei
>>>>>>
>>>>>>
>>>>>> On 3/23/20 17:08, Yasumasa Suenaga wrote:
>>>>>>> Hi Serguei,
>>>>>>>
>>>>>>> Thanks for your comment!
>>>>>>> I uploaded new webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.04/
>>>>>>>
>>>>>>> Also I pushed it to submit repo:
>>>>>>>
>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/fade6a949bd1
>>>>>>>
>>>>>>> On 2020/03/24 7:39, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Yasumasa,
>>>>>>>>
>>>>>>>> The mach5 tier5 testing looks good.
>>>>>>>> The serviceability/sa/ClhsdbPstack.java is failed without fix
>>>>>>>> and is not failed with it.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/23/20 10:18, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Hi Yasumasa,
>>>>>>>>>
>>>>>>>>> I looked at you changes.
>>>>>>>>> It is hard to understand if this fully solves the issue.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.03/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java.frames.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> @@ -34,10 +34,11 @@
>>>>>>>>> public static LinuxAMD64CFrame
>>>>>>>>> getTopFrame(LinuxDebugger dbg, Address rip, ThreadContext
>>>>>>>>> context) {
>>>>>>>>> Address libptr = dbg.findLibPtrByAddress(rip);
>>>>>>>>> Address cfa =
>>>>>>>>> context.getRegisterAsAddress(AMD64ThreadContext.RBP);
>>>>>>>>> DwarfParser dwarf = null;
>>>>>>>>> + boolean unsupportedDwarf = false;
>>>>>>>>> if (libptr != null) { // Native frame
>>>>>>>>> try {
>>>>>>>>> dwarf = new DwarfParser(libptr);
>>>>>>>>> dwarf.processDwarf(rip);
>>>>>>>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> @@ -45,24 +46,33 @@
>>>>>>>>> !dwarf.isBPOffsetAvailable())
>>>>>>>>> ?
>>>>>>>>> context.getRegisterAsAddress(AMD64ThreadContext.RBP)
>>>>>>>>> :
>>>>>>>>> context.getRegisterAsAddress(dwarf.getCFARegister())
>>>>>>>>> .addOffsetTo(dwarf.getCFAOffset());
>>>>>>>>> } catch (DebuggerException e) {
>>>>>>>>> - // Bail out to Java frame case
>>>>>>>>> + if (dwarf != null) {
>>>>>>>>> + // DWARF processing should succeed when the frame is native
>>>>>>>>> + // but it might fail if CIE has language personality routine
>>>>>>>>> + // and/or LSDA.
>>>>>>>>> + dwarf = null;
>>>>>>>>> + unsupportedDwarf = true;
>>>>>>>>> + } else {
>>>>>>>>> + throw e;
>>>>>>>>> + }
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> return (cfa == null) ? null
>>>>>>>>> - : new LinuxAMD64CFrame(dbg, cfa, rip, dwarf);
>>>>>>>>> + : new LinuxAMD64CFrame(dbg, cfa, rip, dwarf,
>>>>>>>>> !unsupportedDwarf);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> @@ -121,13 +131,25 @@
>>>>>>>>> }
>>>>>>>>> return isValidFrame(nextCFA, context) ? nextCFA : null;
>>>>>>>>> }
>>>>>>>>> - private DwarfParser getNextDwarf(Address nextPC) {
>>>>>>>>> - DwarfParser nextDwarf = null;
>>>>>>>>> + @Override
>>>>>>>>> + public CFrame sender(ThreadProxy thread) {
>>>>>>>>> + if (!possibleNext) {
>>>>>>>>> + return null;
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> + ThreadContext context = thread.getContext();
>>>>>>>>> +
>>>>>>>>> + Address nextPC = getNextPC(dwarf != null);
>>>>>>>>> + if (nextPC == null) {
>>>>>>>>> + return null;
>>>>>>>>> + }
>>>>>>>>> + DwarfParser nextDwarf = null;
>>>>>>>>> + boolean unsupportedDwarf = false;
>>>>>>>>> if ((dwarf != null) && dwarf.isIn(nextPC)) {
>>>>>>>>> nextDwarf = dwarf;
>>>>>>>>> } else {
>>>>>>>>> Address libptr = dbg.findLibPtrByAddress(nextPC);
>>>>>>>>> if (libptr != null) {
>>>>>>>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> @@ -138,33 +160,29 @@
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> if (nextDwarf != null) {
>>>>>>>>> + try {
>>>>>>>>> nextDwarf.processDwarf(nextPC);
>>>>>>>>> + } catch (DebuggerException e) {
>>>>>>>>> + // DWARF processing should succeed when the frame is native
>>>>>>>>> + // but it might fail if CIE has language personality routine
>>>>>>>>> + // and/or LSDA.
>>>>>>>>> + nextDwarf = null;
>>>>>>>>> + unsupportedDwarf = true;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> This fix looks like a hack.
>>>>>>>>> Should we just propagate the Debugging exception instead of
>>>>>>>>> trying to maintain unsupportedDwarf flag?
>>>>>>>
>>>>>>> DwarfParser::processDwarf would throw DebuggerException if it
>>>>>>> cannot find DWARF which relates to PC.
>>>>>>> PC at this point is for next frame. So current frame (`this`
>>>>>>> object) is valid, and it should be processed.
>>>>>>>
>>>>>>>
>>>>>>>>> Also, I don't like that DWARF-specific abbreviations (like
>>>>>>>>> CIE, IDE,LSDA, etc.) are used without any comments explaining
>>>>>>>>> them.
>>>>>>>>> The code has to be generally readable without looking into the
>>>>>>>>> DWARF spec each time.
>>>>>>>
>>>>>>> I added comments for them in this webrev.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>>>> I'm submitting mach5 jobs to make sure the issue has been
>>>>>>>>> resolved with your fix.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/20/20 17:55, Yasumasa Suenaga wrote:
>>>>>>>>>> Thanks Chris!
>>>>>>>>>> I'm waiting for reviewers for this change.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yasumasa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2020/03/21 4:23, Chris Plummer wrote:
>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>
>>>>>>>>>>> The failure is due to JDK-8231634, so not something you need
>>>>>>>>>>> to worry about.
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>> On 3/20/20 2:45 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>> Hi Chris,
>>>>>>>>>>>>
>>>>>>>>>>>> I uploaded new webrev which includes reverting change for
>>>>>>>>>>>> ProblemList:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.03/
>>>>>>>>>>>>
>>>>>>>>>>>> I tested it on submit repo
>>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8240956-2-20200320-0814-9586301),
>>>>>>>>>>>> but it has failed in ClhsdbJstackXcompStress.java.
>>>>>>>>>>>> However I think it is not caused by this change because
>>>>>>>>>>>> ClhsdbJstackXcompStress.java tests `jhsdb jstack`, not
>>>>>>>>>>>> mixed mode, it would not parse DWARF.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2020/03/20 13:55, Chris Plummer wrote:
>>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The test has been problem listed so please add undoing
>>>>>>>>>>>>> this to your webrev. Here's the diff that problem listed it:
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/test/hotspot/jtreg/ProblemList.txt
>>>>>>>>>>>>> b/test/hotspot/jtreg/ProblemList.txt
>>>>>>>>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt
>>>>>>>>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt
>>>>>>>>>>>>> @@ -115,7 +115,7 @@
>>>>>>>>>>>>> serviceability/sa/ClhsdbPrintAll.java 8193639 solaris-all
>>>>>>>>>>>>> serviceability/sa/ClhsdbPrintAs.java 8193639 solaris-all
>>>>>>>>>>>>> serviceability/sa/ClhsdbPrintStatics.java 8193639
>>>>>>>>>>>>> solaris-all
>>>>>>>>>>>>> -serviceability/sa/ClhsdbPstack.java 8193639 solaris-all
>>>>>>>>>>>>> +serviceability/sa/ClhsdbPstack.java 8193639,8240956
>>>>>>>>>>>>> solaris-all,linux-all
>>>>>>>>>>>>> serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
>>>>>>>>>>>>> 8193639 solaris-all
>>>>>>>>>>>>> serviceability/sa/ClhsdbScanOops.java
>>>>>>>>>>>>> 8193639,8235220,8230731
>>>>>>>>>>>>> solaris-all,linux-x64,macosx-x64,windows-x64
>>>>>>>>>>>>> serviceability/sa/ClhsdbSource.java 8193639 solaris-all
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Chris
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/16/20 5:07 AM, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This webrev has passed submit repo
>>>>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8240956-20200316-0924-9487169)
>>>>>>>>>>>>>> and additional tests.
>>>>>>>>>>>>>> So please review it:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8240956
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.02/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2020/03/16 21:03, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>> Thank you so much, David!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2020/03/16 21:01, David Holmes wrote:
>>>>>>>>>>>>>>>> On 16/03/2020 9:46 pm, David Holmes wrote:
>>>>>>>>>>>>>>>>> On 16/03/2020 7:20 pm, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I missed loop condition, so I fixed it and pushed to
>>>>>>>>>>>>>>>>>> submit repo.
>>>>>>>>>>>>>>>>>> Could you try again?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk/submit/rev/9c148df17f23
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> webrev is here:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8240956/webrev.02/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Test job resubmitted. Will advise results if it
>>>>>>>>>>>>>>>>> completes before I go to bed :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Seems to have passed okay.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks a lot!
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2020/03/16 16:17, David Holmes wrote:
>>>>>>>>>>>>>>>>>>> Sorry it is still crashing.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>>>>>> # A fatal error has been detected by the Java
>>>>>>>>>>>>>>>>>>> Runtime Environment:
>>>>>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>>>>>> # SIGSEGV (0xb) at pc=0x00007f98ec01e94e,
>>>>>>>>>>>>>>>>>>> pid=13702, tid=13704
>>>>>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment
>>>>>>>>>>>>>>>>>>> (15.0) (fastdebug build
>>>>>>>>>>>>>>>>>>> 15-internal+0-2020-03-16-0640217.suenaga.source)
>>>>>>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM
>>>>>>>>>>>>>>>>>>> (fastdebug
>>>>>>>>>>>>>>>>>>> 15-internal+0-2020-03-16-0640217.suenaga.source,
>>>>>>>>>>>>>>>>>>> mixed mode, sharing, tiered, compressed oops, g1 gc,
>>>>>>>>>>>>>>>>>>> linux-amd64)
>>>>>>>>>>>>>>>>>>> # Problematic frame:
>>>>>>>>>>>>>>>>>>> # C [libsaproc.so+0x494e]
>>>>>>>>>>>>>>>>>>> DwarfParser::process_dwarf(unsigned long)+0x4e
>>>>>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Same as before.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 16/03/2020 4:57 pm, David Holmes wrote:
>>>>>>>>>>>>>>>>>>>> On 16/03/2020 4: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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks for that tip Chris!
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We can see the id. Just need to wait for the builds
>>>>>>>>>>>>>>>>>>>> to complete before submitting the additional tests.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
More information about the serviceability-dev
mailing list