Evgueni Naverniouk Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140221004001

Steps to reproduce:

It would be great if the "too much recursion" error message was detected much sooner. Right now, infinite loops will lock up the browser for a good 5 minutes before the error is thrown and the browser is responsive again.

On Chrome, infinite loops are detected almost instantly and the browser remains responsive.


Actual results:

Browser hangs for too long during infinite loop errors


Expected results:

Browser should be unlocked much sooner.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 10 years ago

Can you post a testcase showing your problem?  "too much recursion" is not the mechanism used to prevent infinite loops; that mechanism should stop the loop after at most 10 seconds.  "too much recursion" is there to avoid overflowing the C stack and crashing...

	Evgueni Naverniouk Reporter
	Comment 2 • 10 years ago

Here is a very simple example. http://jsfiddle.net/rg8mS/1/

Code:

```
// First we create an object that references itself in a key
var object_with_self_reference = {};
object_with_self_reference.self = object_with_self_reference;

// Now, when we call $.extend() with the 'deep' param set to true
// we will create a recursive loop. Chrome is able to detect this
// recursive loop instantly, but Firefox will hang for about 5
// seconds first -- which is long enough for users to think something
// went horribly wrong.
$.extend(true, window, object_with_self_reference);
```

As the objects in question get bigger, the delay also gets bigger. In my production app, I had this occur with two large Backbone.Model objects and the browser would hang for about 10-20 seconds.

Hopefully there's something you guys can do.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 10 years ago

I get a "too much recursion" instantly as far as I can tell on the page linked in comment 2, on Mac.  With a current nightly, at least.

	Jan de Mooij [:jandem]
	Comment 4 • 10 years ago

WFM too with Firefox 27 and 29 on OS X (tested v29 as it's in the UA string in comment 0).

	Evgueni Naverniouk Reporter
	Comment 5 • 10 years ago

I'll see if I can create a better example.

	Evgueni Naverniouk Reporter
	Comment 6 • 10 years ago

So something strange is going on here. That example I posted above is still causing issues for me, but only on my Mac.

- Mac OSX 10.8.4 (Firefox 29.0a2 (2014-02-21)) -- example code takes about 2-5 minutes before an error is seen. Until then I just get a beachball spinning.
- Window 7 (Firefox 29.0a2 (2014-02-21)) -- example code takes about 1 second before an error is seen.
- CentOS Linux (Firefox 27) -- example code takes about 1 second before an error is seen.

Any theories as to what could be going on with my Mac that may have this effect? Any tests I can run to diagnose the issue?

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 10 years ago

Mac has a much larger stack size by default (7MB, vs 1MB on Linux and 900KB or something on Windows).

Which is why I made sure to specify that I'm also testing on a Mac in comment 3....

Just to check, do you see this problem with a clean profile on your Mac?  If not, are you running a JS debugger or something when you see this issue, by any chance?

	Evgueni Naverniouk Reporter
	Comment 8 • 10 years ago

Aha! Indeed the issue does not occur on a clean profile. It looks like it's a combination of:

- Firefox + Firebug Installed + Firebug's Script Tab being enabled

I'll submit this to the Firebug team instead.

Thanks Boris.

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 10 years ago

Ah, Firebug, when enabled, calls a somewhat expensive hook on every function call.  So you end up doing a _lot_ more work per recursive call than you do without Firebug...

That said, I wonder why our slow script dialog isn't catching this.

	Luke Wagner [:luke]
	Comment 10 • 10 years ago

Does this actually hang for 5 minutes?  The slow script dialog should come up after 10 seconds.  If there is an issue, I'd expect it to be on the DOM side of the operation callback hook; easy to verify with a printf.

	Boris Zbarsky [:bzbarsky]
	Comment 11 • 10 years ago

> Does this actually hang for 5 minutes?

Yes.

> I'd expect it to be on the DOM side of the operation callback hook

The DOM's operation callback hook is not being called.  

What I see happening on the testcase in this bug is that we land in js::jit::HandleExceptionBaseline which ends up throwing a "too much recursion" exception itself, with this stack to where we tried to call into JS:

#4  0x00000001058ca221 in nsXPCWrappedJSClass::CallMethod (this=0x1178c3b00, wrapper=0x128973e80, methodIndex=3, info_=0x10f7a0440, nativeParams=0x7fff5f5253e0) at XPCWrappedJSClass.cpp:1501
#5  0x00000001058c2bd9 in nsXPCWrappedJS::CallMethod (this=0x128973e80, methodIndex=3, info=0x10f7a0440, params=0x7fff5f5253e0) at XPCWrappedJS.cpp:520
#6  0x0000000103da1bd9 in PrepareAndDispatch (self=0x12773ce20, methodIndex=3, args=0x7fff5f525540, gpregs=0x7fff5f5254c0, fpregs=0x7fff5f5254f0) at xptcstubs_x86_64_darwin.cpp:122
#7  0x0000000103da063b in SharedStub () at xptcstubs_x86_64_darwin.cpp:35
#8  0x00000001047ff8a6 in jsds_FilterHook (jsdc=0x116ed3b80, state=0x116c6ce80) at jsd_xpc.cpp:359
#9  0x0000000104804ab8 in jsds_ExecutionHookProc (jsdc=0x116ed3b80, jsdthreadstate=0x116c6ce80, type=4, callerdata=0x0, rval=0x7fff5f525930) at jsd_xpc.cpp:630
#10 0x00000001047f25b8 in jsd_CallExecutionHook (jsdc=0x116ed3b80, cx=0x12d5031c0, type=4, hook=0x104804740 <jsds_ExecutionHookProc(JSDContext*, JSDThreadState*, unsigned int, void*, JS::Value*)>, hookData=0x0, rval=0x7fff5f525930) at jsd_hook.cpp:144
#11 0x00000001047f163a in jsd_ThrowHandler (cx=0x12d5031c0, script=0x13943a380, pc=0x117860a3a ":", rvalArg=0x7fff5f525a90, closure=0x116ed3b80) at jsd_hook.cpp:114
#12 0x0000000102c9a598 in js::DebugExceptionUnwind (cx=0x12d5031c0, frame={ptr_ = 140734792637730}, pc=0x117860a3a ":") at OldDebugAPI.cpp:144
#13 0x0000000102881dd3 in js::jit::HandleExceptionBaseline (cx=0x12d5031c0, frame=@0x7fff5f526100, rfe=0x7fff5f526178, calledDebugEpilogue=0x7fff5f525dd7) at IonFrames.cpp:462
#14 0x0000000102881374 in js::jit::HandleException (rfe=0x7fff5f526178) at IonFrames.cpp:635

This makes the loop in js::jit::HandleException take quite a long time, and none of that code ever invokes operation callbacks.

See also bug 682793 and bug 643360 comment 16...