JDK-8336704 : SIGFPE (0x8) When Using JIT with ArithmeticException
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,21,23
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2024-06-24
  • Updated: 2024-08-15
  • Resolved: 2024-07-18
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

A DESCRIPTION OF THE PROBLEM :
When we run the testcase with JDK 17 and JDK 23, the JVM crashes. However, when we disable JIT compilation with the -Xint option, the JVM does not crash and keeps running, which is the expected result. We also tested using other JVMs such as OpenJ9, and OpenJ9 runs continuously as expected.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
java Test.java

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Runs normally and does not stop.
ACTUAL -
JVM crashes with hs_err file as above.

---------- BEGIN SOURCE ----------
class Test {
  int g = 400;
  int e;

  void h() {
    int[] iArr = new int[g];
    for (int j = 0; j < iArr.length; j++)
      iArr[j] = 55954;
    for (int b : iArr)
      for (int a = 1; a < 2000; a++)
        try {
          iArr[32] = 187 / b;
          int var3 = 49294;
          if (var3 <= 49294 / b)
            e = var3;
        } catch (ArithmeticException c) {
        }
  }

  public static void main(String[] d) {
    Test _instance = new Test();
    for (;;)
      _instance.h();
  }
}
---------- END SOURCE ----------

FREQUENCY : always



Comments
Looking at the same Build Search result as for JDK-8331717 and a non-working fix from JDK-8336729 (which is a different issue from JDK-8331717) are strong indicators that this is indeed a dup of JDK-8331717. I will attach this test to JDK-8331717 as well to not lose track of that and verify it once we have a fix.
15-08-2024

Looks like a duplicate of JDK-8331717. Closing as such and leaving it to [~chagedorn] to verify once the fix is ready.
18-07-2024