285862 - stack overflow on recursion method while Array involved

Status: RESOLVED INVALID

(Rhino Graveyard :: Core, defect)

Description

[Igor Zore]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

1. If your RE ends with something*/ the parser seems to try to end a comment
2. Stack overflow when trying to printout the tree of objects with recursion
   (see Object.prototype.getClassName function in example)

Reproducible: Always

Steps to Reproduce:
1.run the web page and see the results and code
2.the problem is commented in html page as red comment
3.download code for Rhino/SpiderMonkey and run as console application


Actual Results:  
1. error whileparsing
2. stack overflow

Expected Results:  
as it works in c implementation (works fine)

Comment 1

[Igor Zore]

I isolatethe RE problem, now it's clear that /}$/ causes the problem while
parsing. I see that object Array cause the problem, but I do not have time to
find out why. I did not add the stach trace.

Comment 2

[Igor Zore]

I found the difference in bevavior between SpiderMonkey and Rhino in RE.
Actually I made a mistake, because I forgot to escape the } in the RE, but
parsers in c works. Sorry. But the Array problem remains still

Comment 3

[Attila Szegedi]

This might or might not help, but with a debugger I see these three methods 
repeatedly on the call stack:

...
c1._c7(c1, Context, Scriptable, Scriptable, Object)
c1.call(Context, Scriptable, Scriptable, Object[])
OptRuntime.callProp0(Object, String, Context, Scriptable)
c1._c7(c1, Context, Scriptable, Scriptable, Object)
c1.call(Context, Scriptable, Scriptable, Object[])
OptRuntime.callProp0(Object, String, Context, Scriptable)
c1._c7(c1, Context, Scriptable, Scriptable, Object)
c1.call(Context, Scriptable, Scriptable, Object[])
OptRuntime.callProp0(Object, String, Context, Scriptable)
...

With following args in callProp0:

thisObj = value = a NativeArray instance
property = "getClazzName"

Comment 4

[Igor Bukanov]

The bug has nothing to do with regular expressions. Here is the reduced test
case that show the essence of the problem:

-------START-----------
Object.prototype.getClazzName = function() 
{

    try {
        this.getClazzName()
    } catch(e) {

        print("EXCEPTION:"+e);
    }

}



var a = [];

a.getClazzName();
print("OK");

-------END-------------

In SpiderMonkey shell its evaluation gives:
~/s> js proto.js 
EXCEPTION:InternalError: too much recursion
OK

which is caused by the fact that Object.prototype is the prototype object for
Array.prototype so calling a.getClazzName() causes infinite recursion.
SpiderMonkey restricts the number of recursive invocations to 1000 or so and
throw InternalError to scripts. 

Rhino does not limit the recursion depth explicitly and instead relies on JVM to
throw StackOverflowException. Now given that typical Java JVM would allow to
nest more then 10000 times and StackOverflow would probably mean a bug in the
script, it was decided not to allow for scripts to catch StackOverflow. And thus
Rhino behaves very propely when it prints:

~/s> java -jar ~/w/js/rhino/tip/build/rhino1_6R2pre/js.jar proto.js 
java.lang.StackOverflowError
js: exception from uncaught JavaScript throw: java.lang.StackOverflowError

For this reason I marking the bug as invalid. 

On the other hand feel free to open an enhancement report to add an option to
control maximal recursion depths in scripts explicitly.

Comment 5

[Attila Szegedi]

Some sort of explict call stack depth control would be a good idea for the 
interpreted mode of Rhino. Since it doesn't use the Java stack, an infinite 
recursion will drive the JVM out of memory, which is much worse than running out 
of stack space of a single thread, since it'll affect all other threads in the 
JVM too, not only the one executing the runaway code.