115717 - java.lang.ArrayIndexOutOfBoundsException on with/try/finally

Status: VERIFIED WORKSFORME

(Rhino Graveyard :: Core, defect)

Description

[Phil Schwartau]

This is the Rhino version of bug 104077 against SpiderMonkey. 
The testcase for this bug is

          mozilla/js/tests/js1_5/Regress/regress-104077.js

It contains twelve examples of try-catch-finally, constructed
under with-blocks. Three of these cause ArrayIndexOutOfBoundsException
errors in Rhino. For convenience, I will attach these three cases below.

Comment 1

[Phil Schwartau]

Attachment: Standalone testcase with the three failing cases

Comment 2

[Phil Schwartau]

The file I have attached has none of the dependencies common
to the JS testsuite. Therefore it may be run by itself in the shell.
For reference, here is the output of the file in the SpiderMonkey shell:

js> load('(path to)/104077.js')

------------  Testing addValues_3() function  -----------
In finally block of addValues_3() function: sum = 7
In finally finally block of addValues_3() function: sum = 8

------------  Testing addValues_4() function  -----------
In finally block of addValues_4() function: sum = 7
In finally finally block of addValues_4() function: sum = 8

------------  Testing addValues_5() function  -----------
In finally block of addValues_5() function: sum = 7
In finally finally block of addValues_5() function: sum = 8



If you do this in Rhino, in both interpreted and compiled modes,
you get an ArrayIndexOutOfBoundsException on each of the three cases.
For this reason, the original testcase above is failing in Rhino.

Comment 3

[Phil Schwartau]

NOTE: the code in the test is rather artificial. Its main point 
is to ensure that code inside a finally-block is always executed, 
no matter what statements (e.g. return;) are above it.

Comment 4

[Norris Boyd]

Added comment to Interpreter.java:

Bug 115717 is due to adding a GOSUB here before
we insert an ENDTRY. I'm not sure of the best way
to fix this; perhaps we need to maintain a stack
of pending trys and have some knowledge of how
many trys we need to close when we perform a
GOTO or GOSUB.

Comment 5

[Phil Schwartau]

This WORKSFORME with a current Rhino build. I notice Norris has 
also had the same experience, and has removed the corresponding 
testcase regress-104077.js from the Rhino skip list "rhino-n.tests".

Therefore I will resolve this bug as WORKSFORME and mark it
Verified as well -

Comment 6

[Phil Schwartau]

Marking Verified WORKSFORME.

The testcase regress-104077.js now passes, and the standalone given
in Comment #1 now gives the same output as SpiderMonkey in Comment #2.

This is true in both the interpreted and compiled modes of Rhino.

Comment 7

[Igor Bukanov]

Targeting as resolved against 1.5R4