This bug was filed from the Socorro interface and is report bp-0d07b082-130a-4b4e-bee2-f09ad2120626 . ============================================================= 1) Install Firebug 1.10 b1 http://getfirebug.com/releases/firebug/1.10/firebug-1.10.0b1.xpi 2) Open Firebug F12 and enable all panels (right click on the toolbar button and pick "Enable All Panel") 3) Restart Firefox 4) Open Firebug, select the Console Panel 5) Execute following in the Command line: var arr = ;arr.push(arr);console.log(arr); -> CRASH --- Somehow related to infinite recursion Tested with: http://hg.mozilla.org/mozilla-central/rev/5c07a681371d Honza
Can you get this to reproduce on debug builds or non-windows builds?
I can reproduce on Linux, but not consistently. https://crash-stats.mozilla.com/report/index/bp-1e5f7c61-32fe-404d-b430-91eaf2120626 https://crash-stats.mozilla.com/report/index/bp-20b49b19-86a7-4da7-a9f3-fd1342120626 https://crash-stats.mozilla.com/report/index/bp-dfc9413d-4e36-44a3-b4e1-5120c2120626
Ah, good to know. I assume this is only with opt builds? I can't repro with a debug build on win or linux; I'll try an opt build next. Jan: on a side-note, it seems like Firebug also has a bug here, presumably an infinite recursion caused by the cyclic array being passed to console.log. Of course the crash should be fixed, but, even after that, FB should be fixed to handle cyclic graphs correctly (by keeping a hash table of visited objects, etc); as is, FB is hanging the browser. Also: it seems that FB is repeatedly hitting the recursion limit and then catching and ignoring the exception.
(In reply to Luke Wagner [:luke] from comment #3) > Jan: on a side-note, it seems like Firebug also has a bug here, presumably > an infinite recursion caused by the cyclic array being passed to > console.log. Of course the crash should be fixed, but, even after that, FB > should be fixed to handle cyclic graphs correctly (by keeping a hash table > of visited objects, etc); as is, FB is hanging the browser. Also: it seems > that FB is repeatedly hitting the recursion limit and then catching and > ignoring the exception. Yep, this is reported here: http://code.google.com/p/fbug/issues/detail?id=3663 We marked it as Firebug 1.10 blocker so, it should be fixed in the final release. Honza
Created attachment 637785 [details] [diff] [review] rm StackIter stack sniffing I found the underlying source of the crash: UncachedInlineCall does not increment regs.pc after it calls popInlineFrame hence *regs.pc stays at JSOP_CALL, even though the args have been popped. Fixing this actually breaks the rejoin logic in js_InternalInterpret which specifically assumes pc has NOT been incremented, so there is no good fix here. This whole stack-sniffing thing is to recover inline calls to natives. This was implemented b/c a year ago I was told by jsdbg2 people that it was needed immediately. Today, this feature is still unused, thus I'm deciding to remove it. If jsdbg2 every decides that it needs the feature, we can add it again without using stack sniffing.
Created attachment 637786 [details] [diff] [review] rm StackIter::sp_ ... and with the above patch, there is no longer any good use of sp other than ReportIsNotFunction. This patch removes a bunch of code and solves the ReportIsNotFunction problem more directly.
Created attachment 637787 [details] [diff] [review] rm StackIter::sp_ Remove dangling TODOs.
Green on try.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b323d6090b21 https://hg.mozilla.org/integration/mozilla-inbound/rev/9933d50de880 (This fixes the issues I was seeing; the expression now terminates in an error or a bunch of nested braces after a few seconds. Jan, can you confirm?)