User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 This crash has been referred to as "pageads" or "adsense" crash. Many reports on Firebug news group. I had to build a workaround into Firebug 1.1. Reproducible: Sometimes Steps to Reproduce: 1.I will attach a web page with complete instructions and links to crashing sites. The problem does take a couple of reloads to show, so it may depend upon the machine you run on. 2. 3. Actual Results: msvcrt.dll + 0x37366 (0x77c47366) SprintPut [mozilla/js/src/jsopcode.c, line 410] js_DecompileCode [mozilla/js/src/jsopcode.c, line 4230] js_DecompileFunction [mozilla/js/src/jsopcode.c, line 4428] JS_DecompileFunction [mozilla/js/src/jsapi.c, line 4154] fun_toString [mozilla/js/src/jsfun.c, line 1543] js_Invoke [mozilla/js/src/jsinterp.c, line 1375] js_Interpret [mozilla/js/src/jsinterp.c, line 3946] js_Invoke [mozilla/js/src/jsinterp.c, line 1394] nsXPCWrappedJSClass::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453] nsXPCWrappedJS::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468] SharedStub [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] XPTC_InvokeByIndex [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2169] XPC_WN_CallMethod [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1455] js_Invoke [mozilla/js/src/jsinterp.c, line 1375] js_Interpret [mozilla/js/src/jsinterp.c, line 3946] js_Invoke [mozilla/js/src/jsinterp.c, line 1394] fun_apply [mozilla/js/src/jsfun.c, line 1699] js_Invoke [mozilla/js/src/jsinterp.c, line 1375] js_Interpret [mozilla/js/src/jsinterp.c, line 3946] js_Invoke [mozilla/js/src/jsinterp.c, line 1394] nsXPCWrappedJSClass::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1453] nsXPCWrappedJS::CallMethod [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 468] SharedStub [mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] jsds_ExecutionHookProc [mozilla/js/jsd/jsd_xpc.cpp, line 682] jsd_CallExecutionHook [mozilla/js/jsd/jsd_hook.c, line 178] jsd_DebugErrorHook [mozilla/js/jsd/jsd_high.c, line 365] js_ReportErrorAgain [mozilla/js/src/jscntxt.c, line 1196] ReportError [mozilla/js/src/jscntxt.c, line 841] js_ReportErrorNumberVA [mozilla/js/src/jscntxt.c, line 1151] JS_ReportErrorFlagsAndNumber [mozilla/js/src/jsapi.c, line 4713] js_GetProperty [mozilla/js/src/jsobj.c, line 3594] JS_GetUCProperty [mozilla/js/src/jsapi.c, line 3028] nsWindowSH::GetProperty [mozilla/dom/src/base/nsDOMClassInfo.cpp, line 4137] XPC_WN_Helper_GetProperty [mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 953] js_GetProperty [mozilla/js/src/jsobj.c, line 3550] js_Interpret [mozilla/js/src/jsinterp.c, line 3691] js_Execute [mozilla/js/src/jsinterp.c, line 1634] JS_EvaluateUCScriptForPrincipals [mozilla/js/src/jsapi.c, line 4296] nsJSContext::EvaluateString [mozilla/dom/src/base/nsJSEnvironment.cpp, line 1100] nsScriptLoader::EvaluateScript [mozilla/content/base/src/nsScriptLoader.cpp, line 813] nsScriptLoader::ProcessRequest [mozilla/content/base/src/nsScriptLoader.cpp, line 711] nsScriptLoader::OnStreamComplete [mozilla/content/base/src/nsScriptLoader.cpp, line 1093] nsStreamLoader::OnStopRequest [mozilla/netwerk/base/src/nsStreamLoader.cpp, line 137] nsMultipartProxyListener::OnStopRequest [mozilla/content/base/src/nsXMLHttpRequest.cpp, line 210] 0x011e8d50

I cannot attach Firebug 1.1.0b6X to this site. I'll have to submit the B6 version for release and then put a URL here.

As I added to my attached HTML test cases, setting the Firebug option Script->DecompileScriptsForSource to false prevents the crash reported here but still crashes FF2.0.0.8 routinely. In particular http://tutorials.zen-cart.com seems to be steady crasher, tho I believe the underlying problem is the same for most of these URLs.

The version of Firebug I used for these tests is now available: http://fireclipse.xucia.com/files/fireclipse/firebug-1.1.0b6.xpi

CC to Justin. This is the most reproducable pageads crash. I've changed its status to see if it can get more attention.

This is a serious problem for Firebug.

Has anyone been able to catch this in a debugger or something? The stack is not that telling (to me, at least) given the fact that the top frames are so generic just about anything could be happening. I'm not going to be around for the next two-ish weeks, unfortunately, and I think if you want this fixed (for Fx 3) you'll have to be quicker than that - assuming, of course, this is reproducible at all on trunk... So, advice: please try and reproduce on Fx 3. If that causes the same issues, please try and get this in a debugger and figure out what's causing this, attach a patch, and ask timeless or shaver or brendan or whatever for review. If you don't get to all of the above before Jan. 1st, you can ask me for review instead, if you prefer. Good luck, and sorry I'm not more help at the moment.

As far as I know this problem does not occur on FF3. I'm not completely sure because I rarely use FF3 because 391280 prevents me from using it with Firebug.

based on the code, the msvcrt offset should be memmove. my first guess would be a gc hazard (which is probably always my guess when it comes to anything related to jsd). could you possibly build ff2 w/ symbols?

I did try to build ff2 for debug, but failed because of 387239, some kind of cairo problem for some linuxes, including the ubuntu 7.1 I am running.

(In reply to comment #11) > I did try to build ff2 for debug, but failed because of 387239, some kind of > cairo problem for some linuxes, including the ubuntu 7.1 I am running. > This bug report states Windows XP as OS. Surely Linux Cairo problems don't stop you from building on win32?

(In reply to comment #12) > This bug report states Windows XP as OS. Surely Linux Cairo problems don't stop > you from building on win32? I eventually succeeded with linux build on FF2, but I can't get it to crash. I don't know if that is because the bug only occurs on Win32 or because the debug build emits so many assert messages to stdout that the timing is completely different from the release build. Yes, building debug on win32 is the logical approach. Unfortunately I don't have the resources to do that.

OK, so I can reproduce this crash for sure, on a win32 branch debug build with symbols. The problem is I'm not sure what to debug, and/or where to look for a fix.

I also don't seem to be able to reproduce this on trunk. Decompile crashes had all this nice work on them done by Jesse. Maybe he can help?

(In reply to comment #14) > OK, so I can reproduce this crash for sure, on a win32 branch debug build with > symbols. The problem is I'm not sure what to debug, and/or where to look for a > fix. > Just to be clear, by "this crash" you mean the one that ends with the stack: msvcrt.dll + 0x37366 (0x77c47366) SprintPut [mozilla/js/src/jsopcode.c, line 410] js_DecompileCode [mozilla/js/src/jsopcode.c, line 4230] js_DecompileFunction [mozilla/js/src/jsopcode.c, line 4428] The reason I say this is that there are a cluster of crashes caused by the same inputs. If I read SPrintPut, I guess that the object being decompiled has been corrupted so that when SprintPut calls memmove it gets garbage. But I read js_DecompileCode I guess I have no clue because js_DecompileCode does not call SPrintPut.

(In reply to comment #15) > I also don't seem to be able to reproduce this on trunk. At the time I did the FF2 tests I also tested on FF3, maybe 3.0a6. Could not get it to crash.

(In reply to comment #16) > (In reply to comment #14) > > OK, so I can reproduce this crash for sure, on a win32 branch debug build with > > symbols. The problem is I'm not sure what to debug, and/or where to look for a > > fix. > > > > Just to be clear, by "this crash" you mean the one that ends with the stack: > msvcrt.dll + 0x37366 (0x77c47366) > SprintPut [mozilla/js/src/jsopcode.c, line 410] > js_DecompileCode [mozilla/js/src/jsopcode.c, line 4230] > js_DecompileFunction [mozilla/js/src/jsopcode.c, line 4428] > > The reason I say this is that there are a cluster of crashes caused by the same > inputs. > > If I read SPrintPut, I guess that the object being decompiled has been > corrupted so that when SprintPut calls memmove it gets garbage. But I read > js_DecompileCode I guess I have no clue because js_DecompileCode does not call > SPrintPut. > I get that, with the extra frames: SprintCString(Sprinter *sp, const char *s) 418 return SprintPut(sp, s, strlen(s)); Decompile(SprintStack *ss, jsbytecode *pc, intN nb) 1920 todo = SprintCString(&ss->sprinter, rval); Which should also answer your question/wtf moment. :-)

Ah, I guess the opt version is inlining the calls? Anyway, at the crash can you see if rval is sensible? Maybe PopOff is giving bogus offsets.

VS told me it was a <Bad Ptr>, but I'm not sure at what point. It seemed to be OK in some frames and not others. :\

Yes, need to keep in mind that this is not reproducible. So the problem is more likely data corruption than bad code. Is it possible that the script being decompiled is in fact garbage collected? Can you find the value of jsdIScript.functionName? If it blank then its a top level or eval level which is GCed as soon as it runs. hey something's coming to me now...notice that the stack has js_ReportErrorAgain [mozilla/js/src/jscntxt.c, line 1196] ReportError [mozilla/js/src/jscntxt.c, line 841] js_ReportErrorNumberVA [mozilla/js/src/jscntxt.c, line 1151] JS_ReportErrorFlagsAndNumber [mozilla/js/src/jsapi.c, line 4713] (again assuming that is the stack you have) (The crashes are much worse with javascript.options.strict) Could the user error causing the report be in a nested function of a top level that is GCed just before the call and before jsd understands that GC happened?

Where can I get the latest beta version of Firebug to be able to reproduce it?

(In reply to comment #22) > Where can I get the latest beta version of Firebug to be able to reproduce it? > http://fireclipse.xucia.com/ But you need to set Firebug->ScriptPanel->Options->ShowEvalSources true and Firebug->ScriptPanel->Options->UseFunctionSource true I had to set these options default to false because of this crash bug. (Also set about:config javascript.options.strict == true to crash often ;-).

Got my Minefield debug build to crash on OS X. I'll attach the backtrace as attachment. Adjusting bug flags.

#0 JS_Assert (s=0x110638c "top < ss->printer->script->depth", file=0x1106124 In that case top and ss->printer->script->depth have the same value 2 which results in an assertion: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/jsopcode.c&rev=3.278&mark=848&#838 Why do we assert? I really don't know the code but why we do a lt and ge compare on the two lines? If no assertion is thrown we run into an OutOfMemory report.

(In reply to comment #25) > Created an attachment (id=295601) [details] > Backtrace on OS X > This trace is slightly different from the win32 ones I am familiar with: it looks like a crash from decompiling an event handler so Firebug can store the source, whereas the others are decompiling during stack-trace-for-UI construction.

Just an update since this bug was filed: 1) Firebug 1.1 users can greatly reduce the chance of crashes if it happens that they don't use AJAX or eval. By default 1.1.0b10+ disables use of script.functionSource. 2) I've completely rewritten the javascript code involved in this bug for Firebug 1.2. It still crashes on this problem. Also note: 3) FF3 does not crash. 4) The developer versions of Firebug have extensive tracing that can give a good idea of what javascript is doing. If anyone wants help in using it let me know (it would make sense to do this on branches/firebug1.2). This crasher is a major problem for Firebug users and I've love to see it fixed. But if it looks like this is going to be a major time sink and then lead to a fix that is too large for FF2 anyway, we could consider an alternative: focus on FF3 + Firebug1.2 and encourage FF2 devs to run Firebug 1.1.0b10 without eval support.

Unfortunately this isn't a blocker for a Firefox release, but will consider any reasonable patch should someone come up with one.

(In reply to comment #29) > Unfortunately this isn't a blocker for a Firefox release, but will consider any > reasonable patch should someone come up with one. > I'm ok with the not blocker part, but the rest makes it sound like it would be ok if this never gets fixed. That's fine if this is decided by weighing tradeoffs. For me it means stopping support of Firebug on FF2.

So like I said before, I can reproduce this fine on windows, and I have a debug branch build around, I just don't know what to do with the info. Timeless, could you help me debug this crash sometime next week (or do it yourself, I don't really care, just trying to be helpful here). It would be useful if this were fixed before Firefox 3...

Debug spam courtesy of timeless.

Noming this since it affects Firebug

(In reply to comment #27) > (In reply to comment #25) > > Created an attachment (id=295601) [details] [details] > > Backtrace on OS X > > > This trace is slightly different from the win32 ones I am familiar with: it > looks like a crash from decompiling an event handler so Firebug can store the > source, whereas the others are decompiling during stack-trace-for-UI > construction. Brendan, should I file the crash on OS X as a new bug?

(In reply to comment #33) > Noming this since it affects Firebug > I believe that this bug has not been reported on FF3/1.9 but only on FF2/1.8. Firebug 1.1+ is now available via http://getfirebug.com/releases

Marking firebug-p2, Really important for firebug but on FF2.

OK, I'm not sure why this was nomed to block 1.9 as it's only in FF2. So, I'm just -'ing on that basis. Please, if this should block some other release, please nom it for the right one, and we'll get it on the right list.

Want-nomming for 1.8.1.x.

gijs: could you try using attachment 302613 [details] [diff] [review]?

(In reply to comment #40) > gijs: could you try using attachment 302613 [details] [diff] [review]? > At the moment I don't have the time, and I probably won't have that time until the end of April (I'm swamped until the 14th, and leave for holidays on the 18th). Sorry. If nobody else can do it, ping me again in May.

Looks like this important bug will die with FF2, not a Firebug priority

Component is obsolete so resolving bugs as INCOMPLETE