SIGSEGV in aarch64 OpenJDK8u
Hi, We got a SIGSEGV while building Apache Ambari and Apache BigTop using OpenJDK8u on AArch64 platform. The segfault happens while running Apache FindBugs. I have extracted the test packages and shared them at (with hs_err log): http://people.linaro.org/~ningsheng.jian/test/findbugs-test.tar.gz Just run test.sh to reproduce this issue. However, the test is large and I am not able to reduce it. This issue only happens on AArch64 OpenJDK8u, i.e. not on JDK9 or Oracle JDK8u. After some bisect work, I found that the failure exists since this patch: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/f9b6277551dc Reverting this patch makes the test passed. However the patch looks good to me (though it is OpenJDK8u only patch) and I don't think it is the direct cause for the issue. Could you please help to look at it and provide some hints or even a fix? log: ----- # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000ffff95425f48, pid=8074, tid=0x0000ffff9c9d5200 # # JRE version: OpenJDK Runtime Environment (8.0_111-b14) (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14) # Java VM: OpenJDK 64-Bit Server VM (25.111-b14 mixed mode linux-aarch64 compressed oops) # Problematic frame: # J 1399 C2 java.util.HashMap.putVal(ILjava/lang/Object;Ljava/lang/Object;ZZ)Ljava/lang/Object; (300 bytes) @ 0x0000ffff95425f48 [0x0000ffff95425e00+0x148] # # Core dump written. Default location: /mnt/share/homes/ninjia02/Work/findbugs-test/core or core.8074 # # An error report file with more information is saved as: # /mnt/share/homes/ninjia02/Work/findbugs-test/hs_err_pid8074.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ----- Thanks, Ningsheng
On 23/03/17 09:32, Ningsheng Jian wrote:
Could you please help to look at it and provide some hints or even a fix?
Thanks, I'm looking at it. Andrew.
Thanks for the test case. That was, as Sherlock Holmes tended to say, quite a three-pipe problem. Please try this patch and let me know. Andrew. diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad +++ b/src/cpu/aarch64/vm/aarch64.ad @@ -15152,7 +15192,7 @@ %} instruct string_indexof(iRegP_R1 str1, iRegI_R4 cnt1, iRegP_R3 str2, iRegI_R2 cnt2, - iRegI_R0 result, iRegI tmp1, iRegI tmp2, iRegI tmp3, iRegI tmp4, rFlagsReg cr) + iRegI_R0 result, iRegINoSp tmp1, iRegINoSp tmp2, iRegINoSp tmp3, iRegINoSp tmp4, rFlagsReg cr) %{ match(Set result (StrIndexOf (Binary str1 cnt1) (Binary str2 cnt2))); effect(USE_KILL str1, USE_KILL str2, USE_KILL cnt1, USE_KILL cnt2, @@ -15170,8 +15210,8 @@ %} instruct string_indexof_con(iRegP_R1 str1, iRegI_R4 cnt1, iRegP_R3 str2, - immI_le_4 int_cnt2, iRegI_R0 result, iRegI tmp1, iRegI tmp2, - iRegI tmp3, iRegI tmp4, rFlagsReg cr) + immI_le_4 int_cnt2, iRegI_R0 result, iRegINoSp tmp1, iRegINoSp tmp2, + iRegINoSp tmp3, iRegINoSp tmp4, rFlagsReg cr) %{ match(Set result (StrIndexOf (Binary str1 cnt1) (Binary str2 int_cnt2))); effect(USE_KILL str1, USE_KILL str2, USE_KILL cnt1,
Aha, yes! It does fix the issue I met! Thanks a lot, Andrew! I was not able to find the misuse of registers around the crash code. Checking jdk9 source, this kind of misuse also exists on those string_indexof supports. Regards, Ningsheng On 24 March 2017 at 22:41, Andrew Haley <aph@redhat.com> wrote:
Thanks for the test case.
That was, as Sherlock Holmes tended to say, quite a three-pipe problem. Please try this patch and let me know.
Andrew.
diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad +++ b/src/cpu/aarch64/vm/aarch64.ad @@ -15152,7 +15192,7 @@ %}
instruct string_indexof(iRegP_R1 str1, iRegI_R4 cnt1, iRegP_R3 str2, iRegI_R2 cnt2, - iRegI_R0 result, iRegI tmp1, iRegI tmp2, iRegI tmp3, iRegI tmp4, rFlagsReg cr) + iRegI_R0 result, iRegINoSp tmp1, iRegINoSp tmp2, iRegINoSp tmp3, iRegINoSp tmp4, rFlagsReg cr) %{ match(Set result (StrIndexOf (Binary str1 cnt1) (Binary str2 cnt2))); effect(USE_KILL str1, USE_KILL str2, USE_KILL cnt1, USE_KILL cnt2, @@ -15170,8 +15210,8 @@ %}
instruct string_indexof_con(iRegP_R1 str1, iRegI_R4 cnt1, iRegP_R3 str2, - immI_le_4 int_cnt2, iRegI_R0 result, iRegI tmp1, iRegI tmp2, - iRegI tmp3, iRegI tmp4, rFlagsReg cr) + immI_le_4 int_cnt2, iRegI_R0 result, iRegINoSp tmp1, iRegINoSp tmp2, + iRegINoSp tmp3, iRegINoSp tmp4, rFlagsReg cr) %{ match(Set result (StrIndexOf (Binary str1 cnt1) (Binary str2 int_cnt2))); effect(USE_KILL str1, USE_KILL str2, USE_KILL cnt1,
On 27/03/17 04:05, Ningsheng Jian wrote:
Aha, yes! It does fix the issue I met! Thanks a lot, Andrew!
I was not able to find the misuse of registers around the crash code.
Checking jdk9 source, this kind of misuse also exists on those string_indexof supports.
Fixed as http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/983fe2075557 Thank you very much for finding this bug and producing the test case. You have averted what would have been a very nasty bug from being in the JDK9 release. JDK8 patch will follow. Andrew.
participants (2)
-
Andrew Haley
-
Ningsheng Jian