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.
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
