461682 - Console doesn't show stack trace for "too much recursion" errors despite stack being available on the error object

Status: RESOLVED WORKSFORME

(DevTools :: Console, enhancement, P2)

Description

[William J. Edney]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3

It would be really great to get better error reporting for a endless recursion than the current simple 'too much recursion' error message, which makes finding the recursing code in large, highly factored codebases difficult.

Maybe a dump of the stack containing the frames that have been detected as being part of the recursion. Other ideas are welcome here.



Reproducible: Always

Steps to Reproduce:
1.Write code that recurses too much :-)
2.
3.
Actual Results:  
Simple error message

Expected Results:  
A more detailed error message, maybe with stack trace

Comment 1

[Tyler Downer [He/Him]]

Not sure where this goes, think maybe Core? But leave that for others.

Comment 2

[Nickolay_Ponomarev]

Core:General is a better place than Firefox:General in any case.

Comment 3

[Jukka Jylänki]

We have been seeing this popping up somewhat often in Emscripten crosscompiled C/C++ sources. A better error message would be very helpful, since now it requires a bit of fudging around to get to the sources. The compiled applications are millions of lines long, generated by a compiler, so utterly incomprehensible for the user.

These are not necessarily cases where Emscripten compiler would have a bug. If the C/C++ code has an infinite recursion (or otherwise unusually long recursion that eventually tips the stack, but does not do so in native), execution will mysteriously fail with the "too much recursion" error and the user is left guessing in the dark.

Comment 4

[Luke Wagner [:luke]]

"Too Much Recursion" does throw an exception that is catchable, and the exception object has a .stack on it.  E.g.:
  (function f() { try { f() } catch(e) { alert(e.stack) } })()
Now, related to asm.js is the problem that the .stack won't contain asm.js calls.  Bug 947996 will add asm.js stack walking which should allow us to fix this.

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Errors use SavedFrame stacks which should see asm.js frames. I'm going to retest.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

For whatever reason, the console isn't showing the stack despite the error object having one.

Comment 7

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: index.html

Can't seem to reproduce with a simple case -- getting an asm.js compiled message, and getting an error thrown displaying the stack trace -- is there a STR for this?

Comment 8

[Jordan Santell [:jsantell] [@jsantell]]

Pinging for the above scenario -- am I misunderstanding (likely) or is this still an issue?

Comment 9

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Seems to WFM now; let's file new bugs with specific test cases and STRs.

Comment 10

[Jukka Jylänki]

Hmm, I think the original issue may have been the lack of asm.js callstacks, which was since fixed like Luke reported. Tried some test cases with Emscripten, and this works ok now.

Comment 11

[William J. Edney]

I reported this long enough ago that I can assure you it was not in regards to asm.js callstacks ;-).

I haven't seen this issue in a while, although I must confess that I don't use Firefox for major development these days, so it may still be an issue.

In any case, as far as me being the original reporter here, I have no problem with folks closing this out.