192288 - 0 / 0 in functions with optimization >= 1 gives bad class code

Status: VERIFIED FIXED

(Rhino Graveyard :: Compiler, defect)

Description

[Igor Bukanov]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Build Identifier: Rhino CVS from 2003-02-07

With optimization set to 1 or higher 0 / 0  in functions leads to bad class code
triggering java.lang.NoSuchFieldError during execution. The bug is present at
least since  Rhino 1.5R3 so its fix has to wait post 1.5R4 time.

A simple test case is a script like

function f() { return 0 / 0; }
f();

which gives java.lang.NoSuchFieldError: jsK_0

This is the reason why ecma/Expressions/11.5.2.js from the test suite currently
fails when jsDriver.pl runs with --engine rhino9

Reproducible: Always

Steps to Reproduce:
Run the following attached test case under Rhino shell with optimization set to
1 or higher.

Actual Results:  
Exception in thread "main" java.lang.NoSuchFieldError: jsK_0
        at org.mozilla.javascript.gen.c1.call(/home/igor/w/js/x/opt.js:1)
        at
org.mozilla.javascript.optimizer.OptRuntime.callSimple(OptRuntime.java:275)
        at org.mozilla.javascript.gen.c2.call(/home/igor/w/js/x/opt.js:3)
        at org.mozilla.javascript.gen.c2.exec(/home/igor/w/js/x/opt.js)
        at org.mozilla.javascript.Context.evaluateReader(Context.java:818)
        at org.mozilla.javascript.tools.shell.Main.evaluateReader(Main.java:363)
        at org.mozilla.javascript.tools.shell.Main.processFileSecure(Main.java:354)
        at org.mozilla.javascript.tools.shell.Main.processFile(Main.java:291)
        at org.mozilla.javascript.tools.shell.Main.processSource(Main.java:283)
        at org.mozilla.javascript.tools.shell.Main.exec(Main.java:103)
        at org.mozilla.javascript.tools.shell.Main.main(Main.java:76)


Expected Results:  
It should print OK.

Comment 1

[Igor Bukanov]

Attachment: Test case

Comment 2

[Phil Schwartau]

Testcase added to JS testsuite:

      mozilla/js/tests/js1_5/Expressions/regress-192288.js

This passes in SpiderMonkey and in Rhino when optimization < 1.
But, as Igor reported, it fails if Rhino optimization is set >=1:

java org.mozilla.javascript.tools.shell.Main -opt 1
                                        -f js1_5/shell.js 
                                        -f js1_5/Expressions/regress-192288.js

[ Exception as given above ]

Comment 3

[Igor Bukanov]

Attachment: Fix: call Codegen.addNumberConstant only once

The bug was caused by a double call to Codegen.addNumberConstant, the first
time correctly from Codegen.visitLiteral and the second time wrongfully from
the loop in emitConstantDudeInitializers where loop index should be used
instead of calling addNumberConstant. As addNumberConstant would return the
same index for same numbers, the bug surfaces only with NaN as
addNumberConstant does not recognizes already added NaN. The bug also visible
only with optimization set to 1 or higher since only then constant folding can
produce NaN literal.

The patch removes the second call to addNumberConstant and uses
ScriptRuntime.NaNobj for NaNs.

It touches Context to make Context.codeBug() public and ScriptRuntime to make
NaN and NaNobj final as a workaround for MS JVM bug can be done without making
these fields mutable.

Comment 4

[Igor Bukanov]

I commited the fix

Comment 5

[Phil Schwartau]

Verified FIXED. The above testcase now passes in the Rhino shell.
I tested with optimization levels set to -1, 0, 1, and 9.

Comment 6

[Igor Bukanov]

Targeting as resolved against 1.5R5