Closed Bug 303821 Opened 19 years ago Closed 16 years ago

Topcrash [@ XPCJSStackFrame::CreateStack] due to deeply recursive scripts

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9

People

(Reporter: timeless, Assigned: mayhemer)

References

(
URL
)

Details

(4 keywords, Whiteboard: See comment 34 for the testcase [firebug-p2])

Crash Data

Attachments

(6 files, 1 obsolete file)

sample Fx1.5.0.2 talkback incident
4.50 KB, text/plain; charset=utf-8
Details
analysis of TB17681340
45.08 KB, text/plain; charset=utf-8
Details
analysis of TB17398587
36.63 KB, text/plain; charset=utf-8
Details
Stacktrace with argument values
31.81 KB, text/plain
Details
This prevents the crash by limiting the number of stack frames we expose...
7.22 KB, patch
Details | Diff | Splinter Review
test case from firebug user issue 476
81 bytes, text/html
Details 
Incident ID: 8093959
Stack Signature	XPCJSStackFrame::CreateStack e183daba
Product ID	FirefoxTrunk
Build ID	2005080306
Trigger Time	2005-08-04 04:59:57.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00021177)
URL visited	
User Comments	
Since Last Crash	34520 sec
Total Uptime	34520 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 141
Stack Trace 	
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 141]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStackFrame::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 144]
XPCJSStack::CreateStack 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcstack.cpp,
line 87]
nsXPCException::NewException 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcexception.cpp,
line 438]
XPCThrower::BuildAndThrowException 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcthrower.cpp,
line 215]
XPCThrower::ThrowBadParam 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcthrower.cpp,
line 147]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2227]
XPC_WN_CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1401]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1173]
js_Interpret 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 3464]
js_Invoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1193]
js_InternalInvoke 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1270]
js_InternalGetOrSet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1313]
js_GetProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2843]
JS_GetProperty 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 2703]
nsXPCWrappedJSClass::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1318]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 462]
SharedStub 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsXULElement::IsFocusable 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 696]
nsIFrame::IsFocusable 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/generic/nsFrame.cpp,
line 4702]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1972]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6434]
PresShell::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 6199]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2559]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsViewManager.cpp,
line 2246]
HandleEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/view/src/nsView.cpp, line
174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1241]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5930]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 6181]
nsWindow::WindowProc 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1418]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp,
line 159]
nsAppStartup::Run 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
main 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)

url contains my more detailed analysis
*** Bug 304711 has been marked as a duplicate of this bug. ***
This is currently a topcrasher in the latest Firefox15 branch
builds:http://talkback-public.mozilla.org/reports/firefox/FF15x/FF15x-topcrashers.html

We should keep an eye on this and try to get a reproducible testcase.  Adding
topcrash and helpwanted keywords.  Nominating, but we should probably wait until
we know more about this before +'ing it.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=XPCJSStackFrame::CreateStack&vendor=MozillaOrg&product=Firefox15&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
Flags: blocking1.8b4?
Keywords: helpwanted, topcrash
Whiteboard: [need testing]
I'm not able to reproduce this crash. I went to a half dozen sites mentioned in
Talkback reports.  Could this somehow be related to bug 200511 (outdated version
of Flash) All the sites I visited in checking for this had Flash content. I
installed version 7 of flash player as suggested by our plugin finder.
I have had Flash 7 for quite some time, but it might be related to FlashBlock. I
did have that installed.
I cannot reproduce this with Adblock or FlashBlock or both running.
Using today's Windows branch build, I cannot reproduce this. I visited all the
sites listed in the search, played around with both Flashblock and Adblock. Will
continue to see if I can reproduce this.
note that we have been experiencing this crash occasionally in our builds, so 
please don't just kill it just because you can't reproduce.
Well, all the crashes appear to be on Firefox builds between 20050812 and
20050816. What was changed on those two dates?
20050812: Fix for 299992 backed out.
20050815: Fix for 299992 back in.

Coincidence?
also see the last few comments in bug 304420 (another topcrasher that hasn't
occured since 08/16, they suspect a fix in split windows may have solved that crash)

can anyone that was seeing this before reproduce it with todays build?
Do we believe the crash is due to fp being a bad ptr, or self?  If fp, I'm at a
loss, since we know of no way for that to happen.

Talkback interpretation gurus, what does that line 141 in xpcstack.cpp mean for
the leaf crash frame?

/be
it should be fp, note that 144 properly points to recursively calling 
CreateStack
|self| can't really be bogus here.  The code is:

135     XPCJSStackFrame* self = new XPCJSStackFrame();
136     JSBool failed = JS_FALSE;
137     if(self)
138     {
139         NS_ADDREF(self);

So if self is bogus then |new| returned a completely bogus pointer.  Seems very
unlikely.
Benjamin, comment 9 is blaming you, I think.

/be
The only change from bug 299992 that I think could possibly affect this stack is
the jsdhash change to use JS_CEILING_LOG2 instead of JS_CeilingLog2:

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=jsdhash.c&branch=&root=/cvsroot&subdir=mozilla/js/src&command=DIFF_FRAMESET&rev1=1.37&rev2=1.38
Not showing up as top crasher in talkback anymore .
Flags: blocking1.8b4? → blocking1.8b4-
No crashes in the latest Talkback data since 8/16.  Marking WFM.  If anyone is
able to reproduce this with a recent nightly trunk or branch build, please check
the stack and reopen if you think this is still around or back.

Any idea what might have "fixed" this one?
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
(In reply to comment #17)
> Any idea what might have "fixed" this one?

Not sure, but the only way fp could be bad is if the context is bad, and bug
300756 could lead through freed memory into such badness.  Cc'ing jst in case he
has a better idea of what fixed this.  If it really went away starting with
builds from the 17th, the hook for that build would probably contain the fix.

/be
just crashed my nightly firefox (2005091406) with this stack.

TB9374453E
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB9374453E

was on http://noter.tdconline.dk/ trying to enter my password when I crashed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The fix referenced in comment 15 didn't fix it. I've just seen the crash and my code base contains that fix.
*** Bug 319019 has been marked as a duplicate of this bug. ***
i just got bitten by this, i think.
talkback: TB14628173Y

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ID:2006011112
I crashed w/ this a couple of weeks ago:

TB15248607H
This is showing up as about 0.32% of crashes for Firefox 1.5.0.2.  The three stacks I looked at were all exactly the same except for the number of levels of recursion at the top of the stack.
The information in talkback isn't adequate here.  If somebody gets the windows crash dialog when seeing this crash ***while using a build that I can download (and you have to say which one)***, could you paste its contents in the bug?
Actually, the Windows incidents are more varied than that, and there are a handful of Linux incidents which have usable data, so I should be able to find something out from the Linux talkback incidents.
Attached file analysis of TB17681340 — 
In this incident, fp is a bad, non-null pointer.
Attached file analysis of TB17398587 — 
In this one, filename is bad.  (But it seems atypical.)

Unfortunately these were the only two Linux incidents fresh enough to analyze; neither seems to fit the typical pattern of the Windows incidents.
It's also worth noting that probably half of the talkback incidents that have comments mention that the crash was on ebay's registration page.
Summary: [@ XPCJSStackFrame::CreateStack] → Topcrash [@ XPCJSStackFrame::CreateStack]
Flags: blocking1.8.1?
Flags: blocking1.8.1? → blocking1.8.1-
Assignee: dbradley → nobody
Status: REOPENED → NEW
QA Contact: pschwartau → xpconnect
I've been doing some statistical analysis of the presence of modules (since we have the list of DLLs loaded with their base addresses, so we can convert the raw stack to something useful) and talkback crash signatures, and it appears that this crash is siginificantly more common for users who have the skype toolbar running (which shows up as PNRComponent.dll and SPhoneParser.dll).

(I'm still looking at pretty small sample sizes, though.)
As bug 416932 shows it still happens for Linux/Windows when opening the site:
http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm

With this test case I get over 23000 calls of XPCJSStackFrame::CreateStack!

The top frames of bp-df131733-d97d-11dc-b2f9-001a4bd43ed6 are:
0       arena_malloc_small       jemalloc.c:3584
1       arena_malloc    jemalloc.c:3691
2       malloc  jemalloc.c:5637
3       operator new(unsigned int)      new.cpp:54
4       XPCJSStackFrame::CreateStack(JSContext*, JSStackFrame*,
XPCJSStackFrame**)      mozilla/js/src/xpconnect/src/xpcstack.cpp:135
5       XPCJSStackFrame::CreateStack(JSContext*, JSStackFrame*,
XPCJSStackFrame**)      mozilla/js/src/xpconnect/src/xpcstack.cpp:144
6       XPCJSStackFrame::CreateStack(JSContext*, JSStackFrame*,
Flags: blocking1.9?
OS: Windows XP → All
Jeff Cook: want to try this under valgrind?  If you can hit it reliably, it might be quite useful.
Flags: blocking1.9? → blocking1.9+
This crash does only happen on the mentioned website if you have Firebug 1.1b10 installed. With my OS X debug build there are 104670 stack frames to load... which looks like a recursion.
Hardware: PC → All
URL: http://viper.haque.net/~timeless/xpc.... → http://www.propagandamatrix.com/artic...
Keywords: testcase
Whiteboard: [need testing] → See comment 34 for the testcase
Henrik, any chance you can get a stack trace with argument values in it? In particular it would be helpful to see the value of the fp argument in CreateStack().
mrbkap, any thoughts on how Firebug could cause a never-ending JS stack frame chain here (assuming that's what's happening)? 
Sure. Just some cycles at the beginning of the recursion which show valid pointers. 'fp->down' will be fp in the next cycle:

(gdb) frame 56
#56 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0xbfffb9ac, stack=0xbfffb3a0) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 55
#55 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0xbfffc35c, stack=0x449e8f6c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 54
#54 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d8b00, stack=0x449e8f8c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 53
#53 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d8a7c, stack=0x449e933c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 52
#52 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d89f8, stack=0x449e935c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 51
#51 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d8974, stack=0x449e937c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 50
#50 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d88f0, stack=0x449e939c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 49
#49 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d886c, stack=0x449e946c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp
(gdb) frame 48
#48 0x136f5349 in XPCJSStackFrame::CreateStack (cx=0x3aa74bb0, fp=0x452d87e8, stack=0x449e948c) at /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp:143
143	in /Users/henrik/Projects/mozilla/source/mozilla/js/src/xpconnect/src/xpcstack.cpp

Better one. I stopped the recursion after 120 cycles.
hmm, interestingly enough that stack trace doesn't show us in a JS stack frame that's pointing back to itself, unless the chain is longer than what's visible in the attached stack trace.
Using firebug 1.2 code under FF2.0.0.12, I get error 
too much recursion
With a stack trace containing a lot of these lines:
(0)http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm:923-929@925
...
(0)http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm:923-929@925
(0)http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm:951-957@953
<bottom>

Then I get a lot of 
onThrow from tag:50:http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm@925: 12
from a method:
    function SymOnLoad() {
        if (SymRealOnLoad != null) {
            SymRealOnLoad();
        }
        window.open = SymRealWinOpen;
        SymRealOnUnload = window.onunload;
        window.onunload = SymOnUnload;
    }
Followed by
debugger.onError: InternalError: too much recursion
<top>
(0)http://www.propagandamatrix.com/articles/february2008/021108_changed_gop.htm:36-38@37
<bottom>

For 1.1b10 I guess from the stack in Comment #39 , ie
#123 0x136da2fa in nsXPCComponents::GetStack 
that the stack that loops is Components.stack. (This part of 1.1 is completely different in 1.2).




I am able to reproduce this at 100% cases with TRUNK from this morning and Firebug 1.1.0b10 on both my Mac and Windows machine. I will take a closer look at this, but will probably need some help soon because I am not expert to JS engine.
Assignee: nobody → honzab
Find shaver, timeless, or me on IRC (try #jsapi for a channel).

/be
Status: NEW → ASSIGNED
The cause is this code embed in the page HTML source:

<script language="JavaScript">
<!--
var SymRealOnLoad;
var SymRealOnUnload;

function SymOnUnload()
{
  window.open = SymWinOpen;
  if(SymRealOnUnload != null)
     SymRealOnUnload();
}

function SymOnLoad()
{
  if(SymRealOnLoad != null)
     SymRealOnLoad();
  window.open = SymRealWinOpen;
  SymRealOnUnload = window.onunload;
  window.onunload = SymOnUnload;
}

SymRealOnLoad = window.onload;
window.onload = SymOnLoad;

//-->
</script>


This piece of code is contained twice it that HTML (it is simply duplicated from some reason!). Please, see the page source. When these two lines:

SymRealOnLoad = window.onload;
window.onload = SymOnLoad;

are executed two times then SymRealOnLoad contains reference to SymOnUnload. Then the function instead of calling the original onload handler calls its self. Probably because it has no arguments nor local vars, many stack frames could be allocated for it (I have about 120'000 on Mac and 230'000 on Win). When the quota is reached then an exception "script stack space quota is exhausted" (021108_changed_gop.htm, line 1017) is thrown. But when Firebug tries to log this exception that extra long stack could not be build up with XPCJSStackFrame::CreateStack recursion because it simply exhausts the machine stack.

I am not sure if this is some bug in the stack depth limitation in the JS interpreter (probably not, because the JS engine lives correctly on) or it is simply too deep for XPCJSStackFrame::CreateStack to make its job in the recursive way (which is obviously natural). 

When you enable Firebug for local files then this simple code reproduce the problem:

...
<body onload="DoSomething();">
<script language="JavaScript">
function DoSomething()
{
        DoSomething();
}
</script>
...

My ideas for solution:

1. changing XPCJSStackFrame::CreateStack implementation to cycle on the linked list would help, but is that the true solution? I believe there are other places those need to turn from recursion to cycle. 

2. Should there still be some hard limit for depth as it was removed with bug 392973? 

3. Just add some limit for recursion depth of XPCJSStackFrame::CreateStack? It is still not the true solution because you cannot be sure how much space on the stack is available for it /and it will not give you complete stack trace /and it is difficult to decide what is the right depth.
That piece of code is injected by Norton System Works to prevent popup windows. Those of us without Norton System Works won't see that code.
If you're referring to the code identified in #44 as the cause of this issue, you're incorrect; I'm using Linux, definitely don't have Norton System Works and running, and still see that code. Perhaps it's injected on the author's side?
Strictly from the debugger's point of view simply counting identical stack frames is sufficient. I don't need 120,000 frames, I'm good with "119,999 frames like this one elided" ;-).


That won't solve:

  function foo() { bar(); }
  function bar() { foo(); }
  bar();

or similar slightly more convoluted variants.
Same results as Honza in comment 44, with a simple testcase:
    function a() { a(); }  a();

Seems like truncating the stack if it's deeper than $BIGNUMBER frames would be an acceptable result -- if you've hit a recursion bug in your code, that should be obvious within the first thousand frames or so.

Is that the root problem, though? Without Firebug, the error console just quickly reports "Error: script stack space quota is exhausted." With Firebug, we're seeing 100K stack frames (albeit C, not JS)... Is debugging causing the "stack space quota" to be ignored? Or are grossly deep stacks like this efficient under normal (non-debugging) circumstances?
As Honza sorted out, I think problem is that Firebug wants to help the dev by reporting the erroneous stack.  Since the stack is large, this 'help' isn't so helpful.  I'll look to see if I can detect this case.
Attached patch Totally untested possible fix. (obsolete) — — Splinter Review 
This could be buggy, or plain wrong and dumb, but it seems like this should work here.

The problem as I understand it is that we're doing JS stuff and we use up a ton of the stack space, then we throw the exception about running out of stack space, and while all that's on the stack, we get into XPCJSStackFrame::CreateStack() and we recursively call that for fp->down, which will be the whole chain of JS calls. This patch makes XPCJSStackFrame not be recursive (modulo bugs, as this is totally untested) and thus it won't use much stack space at all.

XPCJSStackFrame's destructor is also recursive, releasing its caller, so if that happens when the stack is close to full, we could still crash, but seems like this would be worth a try either way. Plus, it's not very likely for GC to happen (or any of the error cases in CreateStack() to triger) with tons of stuff already on the stack.
Comment on attachment 305640 [details] [diff] [review]
Totally untested possible fix.

 XPCJSStackFrame::CreateStack(JSContext* cx, JSStackFrame* fp,
                              XPCJSStackFrame** stack)
 {
+    nsRefPtr<XPCJSStackFrame> top;
+    *stack = top;
     return self ? NS_OK : NS_ERROR_OUT_OF_MEMORY;

Am I wrong in assuming top being a RefPtr results in *stack being freed data?
(In reply to comment #52)
> Am I wrong in assuming top being a RefPtr results in *stack being freed data?

Yeah, that's one of two problems with the patch. It's not worth testing (as confirmed by dolske in person).

Comment on attachment 305640 [details] [diff] [review]
Totally untested possible fix.

This, with the refcounting issues fixed, does fix the crash here, but it exposes the next one, as I suspected in the destructor of XPCJSStackFrame. I've got a patch baking for that too, but I'm also investigating whether it's sane to end up here with a stack that's *thousands* of frames deep...
Attachment #305640 - Attachment is obsolete: true
js> function a(b) { try { a(b) } catch (e) { if (b.stop) return; b.stop=true; var g=0; function z() {++g}; var stack=e.stack; var len = stack.length; var avg = stack.indexOf("\n"); print (len, avg, len/avg); } }; a({})
1048576 28 37449.142857142855

So, you can get ~30,000 frames if you're careful :).
From a sample size of 1 with dolske's simple recurse-to-death sample, we end up with a JS stack that's 130432 frames deep. That seems a bit excessive to me, but I guess that's what we get for giving JS a 512k stack.
So this patch does prevent this crash, but it instead makes the process hang in some sort of loop where it's accessing this stack repeatedly for some reason. IOW, XPCJSStackFrame::CreateStack() is called through a non-obvious path for what looks like the same stack.

This patch limits the stack frame chain length to 1000 (plus 1, plus a dummy frame). It the stack will show the frame where the exception was thrown, and then a dummy frame that shows how many frames were skipped (as the function name), and then the 1000 frames that started this whole mess.

Something seems to be wrong with firebug when we hit an stack quota exceeded exception, and this patch does *not* address that.
In FF2, firebug works fine, it gets "too much recursion" from FF and tells the user. So there must be a difference in FF3, let me know when to look into this when you have a FF3 with your fix.


The builds at https://build.mozilla.org/tryserver-builds/2008-02-26_17:55-jst@mozilla.com-createstackcrash/ contain the last attachment in this bug. Please feel free to test it as much as you can.
Good news and bad news: that build doesn't crash like 3.0b4pre, butinstead it just pegs my CPU. I'll attach the exact file I used, its from
http://code.google.com/p/fbug/issues/detail?id=476

I ran my testcase (comment 49), and got the hang...

It logs on execption to the console, trimmed:

  JavaScript Error: "script stack space quota is exhausted"
  {file: "file:///.../firebug1.2/components/firebug-service.js" line: 1894}
  when calling method: [jsdIExecutionHook::onExecute]"  nsresult:
  "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"
  location: http://people.mozilla.com/~dolske/tmp/infiniteloop.html :: a 

DTrace shows JS activity  during the hang, spinning for more than an hour with a repeated pattern of:

  C    PID  DELTA(us)              FILE:LINE TYPE     -- FUNC
  0  36156          4  firebug-service.js:1887 func     -> apply
  0  36156        229  firebug-service.js:903  func       -> isFilteredURL
  0  36156         61  firebug-service.js:-    func       <- isFilteredURL
  0  36156         57  firebug-service.js:908  func       -> getFrameGlobal
  0  36156        163  firebug-service.js:1903 func         -> getWrappedValue
  0  36156         70  firebug-service.js:-    func         <- getWrappedValue
  0  36156         46  firebug-service.js:-    func       <- getFrameGlobal
  0  36156         50  firebug-service.js:-    func     <- apply
  0  36156      67582  infiniteloop.html:-    func     <- a
  0  36156     228657  firebug-service.js:1887 func     -> apply
  0  36156        198  firebug-service.js:903  func       -> isFilteredURL
  0  36156         55  firebug-service.js:-    func       <- isFilteredURL
  0  36156         55  firebug-service.js:908  func       -> getFrameGlobal
  0  36156        145  firebug-service.js:1903 func         -> getWrappedValue
  0  36156         67  firebug-service.js:-    func         <- getWrappedValue
  0  36156         45  firebug-service.js:-    func       <- getFrameGlobal
  0  36156         52  firebug-service.js:-    func     <- apply
  0  36156      73925  infiniteloop.html:-    func     <- a

:1887 looks to be the JSD hook, :903/:908 are in "onThrow()". Note that there's no "--> a" entry, is this the recursion slowly unwinding?
Comment on attachment 305891 [details] [diff] [review]
This prevents the crash by limiting the number of stack frames we expose...

ok, so the first part of the patch fixes a jsd bug specifically bug 282660 comment 6 (reentrancy).

I don't suppose you'd be willing to split the jsd bug fix into that bug?
(In reply to comment #62)
> I ran my testcase (comment 49), and got the hang...
...
> no "--> a" entry, is this the recursion slowly unwinding?
> 
Could be, the exception would examine each frame looking for catch and calling onThrow where Firebug noodles around to get the frame since it won't be available when we get the error message.  If you had set trackThrowCatch you'd still be waiting ;-).

The correct behavior for the engine in this case is to unwind the stack before processing the throw rather than searching for the catch over and over. But of course that would require the engine to distinguish recursion from other ways of blowing the stack.

If Firebug could get the value of the exception we could take special steps for recursion.

If we had onCatch rather than onThrow-when-there-is-no-catch then this would not happen: we would get two calls, onThrow at the error and onCatch when the handler was found down at the bottom of the stack.  That would be the best solution IMO.

(In reply to comment #63)
> I don't suppose you'd be willing to split the jsd bug fix into that bug?

I'm not, but you're more than welcome to.
Whiteboard: See comment 34 for the testcase → See comment 34 for the testcase [firebug-p2]
Summary: Topcrash [@ XPCJSStackFrame::CreateStack] → Topcrash [@ XPCJSStackFrame::CreateStack] due to deeply recursive scripts
JS stack causing this crash:

0 [native frame]
1 anonymous([xpconnect wrapped jsdIStackFrame @ 0x82b9318 (native @ 0x82b92b0)],
 4, [object Object]) ["file:///D:/Profiles/Testing/extensions/firebug@software.j
oehewitt.com/components/firebug-service.js":1757]
    frame = undefined
    msg = "Error in hook: InternalError: script stack space quota is exhausted s
tack="
    this = [object Object]
2 anonymous(inline = undefined) ["http://mozillalinks.org/wp/wp-content/plugins/
IMM-Glossary/JavaScripts/prototype.js":584]
    this = [object DocumentFragment @ 0x7b0efd8 (native @ 0x77e7060)]
3 anonymous(inline = undefined) ["http://mozillalinks.org/wp/wp-content/plugins/
IMM-Glossary/JavaScripts/prototype.js":584]
    this = [object DocumentFragment @ 0x7b0efd8 (native @ 0x77e7060)]
4 anonymous(inline = undefined) ["http://mozillalinks.org/wp/wp-content/plugins/
IMM-Glossary/JavaScripts/prototype.js":584]
    this = [object DocumentFragment @ 0x7b0efd8 (native @ 0x77e7060)]

537:  if (!Array.prototype._reverse)
        Array.prototype._reverse = Array.prototype.reverse;

584:    reverse: function(inline) {
          return (inline !== false ? this : this.toArray())._reverse();
        },

I applied the patch from Johnny Stenback.
number of frames: 261506

XPCJSStackFrame::CreateStack is then called 261506 times for each frame. Then each frame is being destroyed.
> Then each frame is being destroyed.
It seems to me that there is different problem. Exception thrown (the JS stack quota exhaustion) is captured *in JS* by Firebug. But this again throws the same exception and this way for each frame during stack back.

This is the top of the JS stack:

1 ERROR(text = "onScriptCreated failed: InternalError: script stack space quota
is exhausted") ["file:///D:/Profiles/Testing/extensions/firebug@software.joehewi
tt.com/components/firebug-service.js":1926]
    this = [object BackstagePass @ 0x41a5f20 (native @ 0xcbfb84)]
2 anonymous(script = [xpconnect wrapped jsdIScript @ 0xa9d11c8 (native @ 0xa9d10
f0)]) ["file:///D:/Profiles/Testing/extensions/firebug@software.joehewitt.com/co
mponents/firebug-service.js":1076]
    fileName = "XPCSafeJSObjectWrapper.cpp"
    this = [object Object]
3 anonymous([xpconnect wrapped jsdIScript @ 0xa9d11c8 (native @ 0xa9d10f0)]) ["f
ile:///D:/Profiles/Testing/extensions/firebug@software.joehewitt.com/components/
firebug-service.js":1752]
    frame = undefined
    msg = undefined
    this = [object Object]
4 anonymous(win = [object Window @ 0x4452a78 (native @ 0x447e554)]) ["chrome://f
irebug/content/tabWatcher.js":296]
    context = undefined
    i = undefined
    this = [object Object]
5 anonymous(win = [object Window @ 0x4452a78 (native @ 0x447e554)]) ["chrome://f
irebug/content/debugger.js":571]
    context = undefined
    this = [object Object]
6 [native frame]
7 anonymous(frame = [xpconnect wrapped jsdIStackFrame @ 0xa9c55d8 (native @ 0xa9
c5570)]) ["file:///D:/Profiles/Testing/extensions/firebug@software.joehewitt.com
/components/firebug-service.js":1242]
    debuggr = [xpconnect wrapped nsIFireBugDebugger @ 0x546da20 (native @ 0x5338
550)]
    i = 0
    win = [object Window @ 0x4452a78 (native @ 0x447e554)]
    this = [object Object]
8 anonymous(arguments = [object Object], rv = [object Object], type = 4, frame =
 [xpconnect wrapped jsdIStackFrame @ 0xa9c55d8 (native @ 0xa9c5570)]) ["file:///
D:/Profiles/Testing/extensions/firebug@software.joehewitt.com/components/firebug
-service.js":867]
    debuggr = undefined
    this = [object Object]
9 anonymous(arguments = [object Object], 4, [object Object]) ["file:///D:/Profil
es/Testing/extensions/firebug@software.joehewitt.com/components/firebug-service.
js":1752]
    frame = undefined
    msg = undefined
    this = [object Object]
10 anonymous(arguments = [object Object], inline = undefined) ["http://mozillali
nks.org/wp/wp-content/plugins/IMM-Glossary/JavaScripts/prototype.js":584]
    this = [object DocumentFragment @ 0x5c31de0 (native @ 0x5c34c80)]
11 anonymous(arguments = [object Object], inline = undefined) ["http://mozillali
nks.org/wp/wp-content/plugins/IMM-Glossary/JavaScripts/prototype.js":584]
    this = [object DocumentFragment @ 0x5c31de0 (native @ 0x5c34c80)]
12 anonymous(arguments = [object Object], inline = undefined) ["http://mozillali
nks.org/wp/wp-content/plugins/IMM-Glossary/JavaScripts/prototype.js":584]
Well we could look into details, but it seems to me that if the stack is exhausted then we can't expect anything good to happen until we recover from that. Two choices:
  1) Provide a small recovery buffer on the stack that allows the debugger enough headroom to run,
  2) Always roll back the stack on this error, but that means analyzing the recursion which will be hard.

Or is there something more than "debugger running on full stack" ?

I am a bit confused by this statement in Comment 67: 
XPCJSStackFrame::CreateStack is then called 261506 times for each frame.
Did you mean 
XPCJSStackFrame::CreateStack is then called 261506 times *once* for each frame. 
Or did you mean 261506 times for each of 261506 frames?  Seems like a lot ;-)

(In reply to comment #69)
> I am a bit confused by this statement in Comment 67: 
> XPCJSStackFrame::CreateStack is then called 261506 times for each frame.
> Did you mean 
> XPCJSStackFrame::CreateStack is then called 261506 times *once* for each frame. 
> Or did you mean 261506 times for each of 261506 frames?  Seems like a lot ;-)
> 

Sorry for that confusion :) This number is probably completely wrong observation. The method was simply called multiple times by Firebug and I deduced from it that it is called ones per each frame as they are being rolled back.
Blocks: 411814
Depends on: 424683
I can tell you this is a serious issue for Amazon.com developers because we cannot open the majority of the site pages in internal debug mode and many of us are using Firebug.
Fixing bug 424683 will also help this, I think -- can someone build with the most recent patch in that bug and see if it does?
(In reply to comment #71)
> I can tell you this is a serious issue for Amazon.com developers because we
> cannot open the majority of the site pages in internal debug mode and many of
> us are using Firebug.
> 

I am concerned that there is another bug here. This report concerns a crash that only happens when two things are true:
  1) Your page has an infinite loop
  2) You are running firebug.
If you don't have an infinite loop and you are still crashing with firebug we need to find out why.
The testcase from comment #61 is fixed by the landing of bug 424683, so I think this bug can generally be considered fixed.  Other issues should go to other bugs.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago → 16 years ago
Resolution: --- → FIXED
I see the testcase in comment #61 passes with FF3b5.  I was responding in comment #71 to John Barton's comment #66 because I've been generating almost identical crash reports to the one he referenced.  Is there a separate bug for that issue?
(In reply to comment #75)
> I see the testcase in comment #61 passes with FF3b5.  I was responding in
> comment #71 to John Barton's comment #66 because I've been generating almost
> identical crash reports to the one he referenced.  Is there a separate bug for
> that issue?
> 
Please post the URL for your crash. We can't help you without either the stack from your crash or the page you crash on and the version you are running.

Now I can't reproduce it (with FF3b5 and Firebug 1.2.0a13x), but for reference, these crash reports were the latest.

http://crash-stats.mozilla.com/report/index/599cebb0-01d8-11dd-88de-001a4bd43e5c
http://crash-stats.mozilla.com/report/index/874f1e8c-01d5-11dd-8a54-001a4bd43e5c

No crash anymore with the testcase and loading the given URL.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041005 Minefield/3.0pre ID:2008041005

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008041104 Minefield/3.0pre ID:2008041104

paxunix, in your mentioned crash reports you can see that the build identifiers are too old. The patch went in later.

Tests were added on bug 424683.
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
Flags: in-litmus-
Target Milestone: --- → mozilla1.9
No longer blocks: 411814
Crash Signature: [@ XPCJSStackFrame::CreateStack]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: