JDK-8261397 : try catch Method failing to work when dividing an integer by 0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11,15.0.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2021-02-04
  • Updated: 2021-10-05
  • Resolved: 2021-02-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15 JDK 16 JDK 17 JDK 8
11.0.12-oracleFixed 13.0.8Fixed 15.0.4Fixed 16.0.1Fixed 17 b11Fixed 8u311Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
macOS Big Sur 11.2

A DESCRIPTION OF THE PROBLEM :
Anytime a divide any integer value in a System.out.println() by 0, utilizing a try-catch statement to deal with this ArithmeticException, a message pops up on my screen stating "A fatal error has been detected by the Java Runtime Environment." Another thing, is whenever I write System.out.println(1/0); or any integer being divided by 0, my entire IDE crashes immediately without the program even being run (Eclipse).

ERROR MESSAGES/STACK TRACES THAT OCCUR :
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x000000011778d168, pid=1403, tid=7427
#
# JRE version: Java(TM) SE Runtime Environment (15.0.1+9) (build 15.0.1+9-18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (15.0.1+9-18, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# j  Arithmetic_Exception.main([Ljava/lang/String;)V+4
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/shaheer/eclipse-workspace/Handling_Exception_(Throws)/hs_err_pid1403.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Int x=1;   // Can be any integer
int y=0;
System.out.println(x/y)    // Even a try-statement cannot deal with this

//Second bug
System.out.println(1/0)    //Can be any integer as the numerator.
                           // Any time this gets written out, the entire IDE will crash without even running the program

ACTUAL -
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x000000011778d168, pid=1460, tid=8963
#
# JRE version: Java(TM) SE Runtime Environment (15.0.1+9) (build 15.0.1+9-18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (15.0.1+9-18, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# j  Arithmetic_Exception.main([Ljava/lang/String;)V+4
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/shaheer/eclipse-workspace/Handling_Exception_(Throws)/hs_err_pid1460.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------- BEGIN SOURCE ----------
public class Arithmetic_Exception {
public static void main(String[] args) {
	int x=5;
	int y=0;
	try {System.out.println(x/y);}
	catch(ArithmeticException A) {System.out.println("y cannot be 0");}
}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I haven't found any workaround, I simply just avoid it. Albeit, this hinders me a lot when I am working.

FREQUENCY : always



Comments
Fix Request (8u), Backporting this low-risk Mac OS specific fix prevents this bug from occurring in JDK-8u. Patch didn't apply cleanly due to missing macro in jdk8u. To be on par with Oracle Review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014324.html
05-10-2021

Fix Request (11u) Backporting this low-risk Mac OS specific fix prevents this bug from occurring in JDK-11u. Patch didn't apply cleanly due to missing macro in jdk13u. Review link https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-March/005515.html ( I will update copyright years for final commit). Checked the fix with reproducer.
30-03-2021

Fix Request (15u) Backporting this low-risk Mac OS specific fix prevents this bug from occurring in JDK-15u. Patch applies cleanly
30-03-2021

Fix Request (13u) Backporting this low-risk Mac OS specific fix prevents this bug from occurring in JDK-13u. Patch didn't apply cleanly due to missing macro in jdk13u. Review link https://github.com/openjdk/jdk13u-dev/pull/164 . Checked the fix with reproducer.
30-03-2021

Fix Request (16u) Backporting this low-risk Mac OS specific fix prevents this bug from occurring in JDK-16u. The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Mac OS.
04-03-2021

Changeset: 0257caad Author: Gerard Ziemski <gziemski@openjdk.org> Date: 2021-02-23 16:38:53 +0000 URL: https://git.openjdk.java.net/jdk/commit/0257caad
23-02-2021

It was closed as incomplete, a part of the process to receive additional info from the submitter. Now that the info has been received (questions answered, hs_err file added), I am reopening this issue.
17-02-2021

Why was it closed?
17-02-2021

This is an issue with ARM hardware running x86 version of JDK under Rosetta emulation.
17-02-2021

additional information from submitter: ========================================== I am currently using a MacBook Pro with the Apple M1 Chip that runs on ARM hardware. ==========================================
17-02-2021

additional information requested from submitter: ================================================= Could you please provide the complete hs_err_pid.log file for further analysis? Also, could you please confirm if your CPU is running on x86_64 hardware or x86_64 binary on ARM hardware? =================================================
17-02-2021

Can the submitter please provide the full hs_err log file that was generated from the crash. Also can we confirm that this was running on x86_64 hardware and not running an x86_64 binary on ARM hardware? Thanks.
17-02-2021

Is there a link to any public information about this bug? Does this affect all JDK versions? Surely we have a TCK test for division-by-zero that should have exposed this issue? !!!
17-02-2021

Looks like Apple might fix it in a future release, but the current macOS is stuck with the bug that needs us to work around it.
16-02-2021

ILW = HLM = P3
16-02-2021

Issue is not reproduced on Windows and Linux. OS: Windows 10 JDK 15.0.2: Pass JDK 16ea32:Pass JDK 17ea2:Pass OS: Oracle Linux 7.6 JDK 15.0.2: Pass JDK 16ea32:Pass JDK 17ea2:Pass As submitter has reported it on Mac OS Big sur 11.2 so moving it to dev team for further analysis.
09-02-2021