JDK-4427606 : ArithmeticException: / by 0 thrown in remainder operation with positive constant
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS:
    generic,linux,solaris,solaris_2.6,solaris_7,solaris_8 generic,linux,solaris,solaris_2.6,solaris_7,solaris_8
  • CPU: generic,x86,sparc
  • Submitted: 2001-03-20
  • Updated: 2001-05-14
  • Resolved: 2001-04-16
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.
Other
1.4.0 betaFixed
Related Reports
Duplicate :  
JDK-4426365 - RAS: VTEST failed imtermittenly on Solaris x86 with Merlin b55 -client
Duplicate :  
JDK-4436388 - VMark intermitten failure on Solaris Sparc with Merlin b58 -client flag
Duplicate :  
JDK-4445487 - RAS: Vtest client intermitten error in merlin_b59 c1 on linux redhat 6.2
Duplicate :  
JDK-4435036 - Source build fails in javadoc run.
Duplicate :  
JDK-4425356 - RAS: VolanoTest intermitten failure on Linux RedHat with Merlin b54 b55 -client
Duplicate :  
JDK-4434219 - test/java/text/Format/Bug4407042.java fails with exceptions
Duplicate :  
JDK-4423446 - RAS: VM: Reliability Test crashes in build 54 with assertion at os.cpp, 726
Relates :  
JDK-4434239 - Linux: client hs crashes with executing test/java/text/Format/Bug4407042.java
Description
Regression test: java/text/Format/Bug4407042.java failed with jdk1.4 beta b56 on Solaris sparc 8 tw.UTF8 and C locale.

Below is a part of a message:

#section:main
----------messages:(3/120)----------
command: main Bug4407042
reason: Assumed action based on file name: run main Bug4407042 
elapsed time (seconds): 73.418
----------System.out:(0/0)----------
----------System.err:(10/616)----------
java.lang.ArithmeticException: / by zero
        at java.util.GregorianCalendar.timeToFields(GregorianCalendar.java:1333)
        at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1246)
        at java.util.Calendar.setTimeInMillis(Calendar.java:940)
        at java.util.Calendar.setTime(Calendar.java:919)
        at java.text.SimpleDateFormat.format(SimpleDateFormat.java:417)
        at java.text.SimpleDateFormat.format(SimpleDateFormat.java:407)
        at java.text.DateFormat.format(DateFormat.java:309)
        at Bug4407042$DateFormatThread.run(Bug4407042.java:72)
STATUS:Failed.`main' threw exception: java.lang.ArithmeticException: / by zero
result: Failed. Execution failed: `main' threw exception: java.lang.ArithmeticException: / by zero

It passed on windows. 



keiko.nakayama@Eng 2001-03-19


naveena.suryadevara@Eng 2001-04-05

JDK version    : Merlin beta build# 58
Regression test: java/text/Format/Bug4407042.java
Failing on OS  : Solaris6,8 and linux(Redhat6.2)

NOTE: 1.Exceptions throwing are different on solaris and linux OS
        Please see below. 
      2.Passing on Sol6-x86, winNT,win2000,win98

Part of the test results from sol8:
-----------------------------------
#section:main
----------messages:(3/119)----------
command: main Bug4407042
reason: Assumed action based on file name: run main Bug4407042 
elapsed time (seconds): 9.075
----------System.out:(0/0)----------
----------System.err:(12/726)----------
java.lang.ArithmeticException: / by zero
        at java.text.DigitList.set(DigitList.java:478)
        at java.text.DecimalFormat.format(DecimalFormat.java:548)
        at java.text.DecimalFormat.format(DecimalFormat.java:501)
        at java.text.NumberFormat.format(NumberFormat.java:246)
        at java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:666)
        at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:554)
        at java.text.SimpleDateFormat.format(SimpleDateFormat.java:427)
        at java.text.SimpleDateFormat.format(SimpleDateFormat.java:407)
        at java.text.DateFormat.format(DateFormat.java:309)
        at Bug4407042$DateFormatThread.run(Bug4407042.java:72)
STATUS:Failed.`main' threw exception: java.lang.ArithmeticException: / by zero
result: Failed. Execution failed: `main' threw exception: java.lang.ArithmeticException: / by zero


test result: Failed. Execution failed: `main' threw exception: java.lang.ArithmeticException: / by zero

Part of the test results from linux:
------------------------------------
#section:main
----------messages:(3/120)----------
command: main Bug4407042
reason: Assumed action based on file name: run main Bug4407042 
elapsed time (seconds): 69.905
----------System.out:(0/0)----------
----------System.err:(11/582)----------
java.lang.NullPointerException
        at java.lang.String.charAt(String.java:434)
        at java.lang.Long.parseLong(Long.java:308)
        at java.lang.Long.parseLong(Long.java:363)
        at java.text.DigitList.getLong(DigitList.java:153)
        at java.text.DecimalFormat.parse(DecimalFormat.java:986)
        at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1050)
        at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:793)
        at java.text.DateFormat.parse(DateFormat.java:326)
        at Bug4407042$DateParseThread.run(Bug4407042.java:48)
STATUS:Failed.`main' threw exception: java.lang.NullPointerException
result: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException


test result: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException


al.smith@eng 2001-04-17
Regression test java/text/Format/Bug4407042.java fails in build 60. Will verify integration in b61.

--------
verified the fix with jdk1.4 b63.
The test/java/text/Format/Bug4407043.java passed on the tw.UTF8 and C on solaris sparc 8 with client VM.


keiko.nakayama@Eng 2001-05-06
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta FIXED IN: merlin-beta merlin-beta2 INTEGRATED IN: merlin-beta merlin-beta2 VERIFIED IN: merlin-beta
14-06-2004
PUBLIC COMMENTS In several instances, branches were being made safepoints when they should not h ave been. In particular branches that were part of the explicit division by zer o check for ldiv were safepoints. In build 56 code which was preserving the con dition codes in the illegal instruction handler on sparc was removed because it was believed to no longer be necessary. In fact it isn't necessary as long as c onditional branches aren't safepoints, unfortunately there was a small amount of code which was still making them safepoints. This bug was also the source of c rashes on intel.
10-06-2004
EVALUATION The exception occurs at GregorianCalendar.java line 1333. Its code is: dayOfWeek = (int)((gregorianEpochDay+1) % 7); The last change for GregorianCalendar.java is: /* * @(#)GregorianCalendar.java 1.60 01/02/09 * The same regression test runs OK with b55. So, I suspect this is a Solaris hotspot problem. I'd like the hotspot team to take a look at this problem. masayoshi.okutsu@Eng 2001-03-21 Please attach or add testcase or path i.e: /net/machine.domain/disk1/testcase so I can re-produce this bug. Please re-test this on build 57 as well. This may be a classes_text or classes_lang test failure. Need testcase to go any further. gary.collins@East 2001-03-26 ---- It's reproducible with jdk1.4 beta b57. The path for the test case is: /ws/jdk1.4/test/java/text/Format/Bug4407402.java I used the jtreg in /usr/local/java/sqe-tools2.1.4beta/solaris to run the test case. keiko.nakayama@Eng 2001-03-26 Correct filename is Bug4407042.java. And, a similar problem sometimes occurs at different place as follows. % /usr/local/java/jdk1.4/solsparc/bin/java Bug4407042 java.lang.ArithmeticException: / by zero at java.text.DigitList.set(DigitList.java:478) at java.text.DecimalFormat.format(DecimalFormat.java:548) at java.text.DecimalFormat.format(DecimalFormat.java:501) at java.text.NumberFormat.format(NumberFormat.java:246) at java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:666) at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:646) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:427) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:407) at java.text.DateFormat.format(DateFormat.java:309) at Bug4407042$DateFormatThread.run(Bug4407042.java:72) % /usr/local/java/jdk1.4/solsparc/bin/java -version java version "1.4.0-internal" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-internal-b57) Java HotSpot(TM) Client VM (build 1.4.0-beta-b57, mixed mode) And, line 478 in DigitList.java is 478 digits[--left] = (byte) ('0' + (source % 10)); yuka.kamiya@japan 2001-03-27 The test program is in Attachments. (This version was revised so that it runs without jtreg.) It's still reproducible using b58 (only on Solaris). $ /usr/local/java/jdk1.4/solsparc/bin/java -showversion Bug4407042 java version "1.4.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b58) Java HotSpot(TM) Client VM (build 1.4.0-beta-b58, mixed mode) java.lang.ArithmeticException: / by zero at java.util.GregorianCalendar.timeToFields(GregorianCalendar.java:1381) at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1294) at java.util.Calendar.setTimeInMillis(Calendar.java:919) at java.util.Calendar.setTime(Calendar.java:898) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:417) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:407) at java.text.DateFormat.format(DateFormat.java:309) at Bug4407042$DateFormatThread.run(Bug4407042.java:74) Line 1381 of GregorianCalendar.java in B58 is: dayOfWeek = (int)((gregorianEpochDay+1) % 7); masayoshi.okutsu@Eng 2001-04-05 This problem is reproducible with only client hotspot vm. masayoshi.okutsu@Eng 2001-04-05 The above in not correct for me. The problem exists in all options. I ran this test on a pretty fast system that is stacked and this test passed on merlin and failed on ladybird. After a little time I was able to determine that the clone() call was the culprit for ladybird. But the test did work fine in merlin release. I beleive the issue lies in the util classes or classes related to SimpleDateFormat. Moving this bug to the classes_text area gary.collins@East 2001-04-05 The reference to Ladybird is irrelevant: Bug 4407042 was first reported against 1.1.7, and was only fixed in Merlin-beta. The issue here is that in several different cases an ArithmeticException is thrown where the source code contains a remainder operation with a non-zero constant. It appears that the bug doesn't appear in all configurations, but I just reproduced it again on my Ultra 1, Solaris 2.6, locale en_US, with the following runtime: java version "1.4.0-beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b58) Java HotSpot(TM) Client VM (build 1.4.0-beta-b58, mixed mode) I checked the byte codes for the various methods where the exception is thrown using javap on build B58: java.util.GregorianCalendar.timeToFields(GregorianCalendar.java:1381): dayOfWeek = (int)((gregorianEpochDay+1) % 7); 232 lload 13 234 lconst_1 235 ladd 236 ldc2_w #82 <Long 7> 239 lrem 240 l2i 241 istore 8 243 goto 328 java.text.DigitList.set(DigitList.java:478) digits[--left] = (byte) ('0' + (source % 10)); 64 aload_0 65 getfield #4 <Field byte digits[]> 68 iinc 4 -1 71 iload 4 73 ldc2_w #29 <Long 48> 76 lload_1 77 ldc2_w #31 <Long 10> 80 lrem 81 ladd 82 l2i 83 i2b 84 bastore In both cases, the lrem instructions are guaranteed to find positive integers as divisors. It's a VM error that the exception is thrown. norbert.lindenberg@Eng 2001-04-05 Still looking into this. This bug is no doubt an intermittent issue for client version. Was able to re-produce this on SunOS dump.east 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-1 after updating the patches. On a side not I am seeing alot of text bugs coming across that deal with long assigns. This may be a long issue in either the JDK or JVM. gary.collins@East 2001-04-06 Comments from Thomas. So we've tracked down the source of the bug. Here's a little snippet of > assembly which shows the problem: > > 0xf9cf5778: nop ;*ldiv > ; - java.text.DigitList::set@89 > > 0xf9cf577c: orcc %o1, %o0, %g0 > 0xf9cf5780: be %icc, f9cf59e0 ; {safepoint} > 0xf9cf5784: nop ;*ldiv > ; - java.text.DigitList::set@89 > > This is the code emitted by explicit_div_by_zero_check(). The "be" instruction > is marked as a safepoint so if we safepoint there, the condition codes will get > destroyed. It used to be that the illegal_instruction_handler for sparc > preserved the condition codes but it was believed that we didn't need to anymore > and the code was removed, which uncovered this problem with lrem/ldiv. Since > they weren't preserved, it was somewhat random whether it threw a div by zero > error or not. It could also cause a crash since the oopmap for this safepoint > probably isn't correct which is most likely why one of the bugs was a crash on > linux. > > The fix suggested by srdjan is to make sure that none of the LIR branches are > safepoints. The smallest fix for this for merlin_beta is to just swallow the > CodeEmitInfos inside LIR_List::branch. For beta refresh, we'll clean up the LIR > interface to reflect these changes. I've tested with moes program and the > problem isn't reproducible. I also tested Bug4407042.java and didn't see > failures but I didn't always see failures without the fix. Please review the > webrev at: > > http://javaweb/~never/webrev/divbyzero > > What should be done about all the other bug reports that seems to be duplicates > of this? They all seem to be very intermittent but we have a pretty reliable > test case now. I guess my real question is: what bug report do I claim I'm > fixing and what do I do about all the other intermittent failures? > > tom gary.collins@East 2001-04-10 thomas.rodriguez@eng 2001-04-10 Gary has already attached my comments so there isn't much to add. This bug is the source of several other bugs and this bug report is going to be the canonical report since the bug was discovered while investigating this bug report. I have a tested fix ready in a child of merlin_beta. We've confirmed that it fixed several other bugs. thomas.rodriguez@eng 2001-04-10 Here is the list related bugs and their synopsis: 4436388 VMark intermitten failure on Solaris Sparc with Merlin b58 -client flag 4435036 Source build fails in javadoc run. 4434684 JCK13a 5 api/java_security/ failed with ArithmeticException: / by zero -Xincgc 4434219 test/java/text/Format/Bug4407042.java fails with exceptions 4423446 RAS: VM: Reliability Test crashes in build 54 with assertion at os.cpp, 726 Also here is the test code that reproduces the bug everytime: /* * To build: javac TestDivByZero.java * To run: java TestDivByZero * * I hope an iteration of 10000000 is enough to reproduce the problem in the future. This test has already been added to the vm testbase by Maneesh Pawar. */ public class TestDivByZero { public static void main(String[] args) { new TestDivByZero().run(); } public void run() { new DivByZero().start(); new NeverDivByZero().start(); } class DivByZero extends Thread { public void run() { long source = 1L; while (true) { try { long ignore = source % zero; throw new RuntimeException("Should Not Reach Here...."); } catch (java.lang.ArithmeticException ax) { /* We better get one of these all the time */ } catch (RuntimeException rx) { rx.printStackTrace(); System.exit (1); } } } } class NeverDivByZero extends Thread { public void run() { long source = 1L; long iter = while (--iter > 0) { try { long ignore = source % notzero; } catch (java.lang.ArithmeticException ax) { ax.printStackTrace(); System.exit (1); } } System.exit(0); } } long zero = 0; long notzero = 10; } mohammad.gharahgouzloo@Eng 2001-04-10
10-04-2001