Last Comment Bug 282660 - Crash [@ jsds_NotifyPendingDeadScripts] ds->script is null
: Crash [@ jsds_NotifyPendingDeadScripts] ds->script is null
: crash, topcrash, verified1.8.1.15
Product: Other Applications
Classification: Client Software
Component: Venkman JS Debugger (show other bugs)
: Trunk
: All All
: -- critical with 1 vote (vote)
: mozilla1.9beta5
Assigned To: timeless
: Christopher Aillon (sabbatical, not receiving bugmail)
: 282658 438691 (view as bug list)
Depends on:
Blocks: 397959
  Show dependency treegraph
Reported: 2005-02-17 18:22 PST by timeless
Modified: 2008-07-09 22:04 PDT (History)
25 users (show)
mtschrep: blocking1.9-
brendan: blocking1.9?
dveditz: blocking1.8.1.5-
dveditz: blocking1.8.1.15+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

wallpaper (707 bytes, patch)
2007-06-22 07:59 PDT, timeless
dveditz: review-
Details | Diff | Splinter Review
Test case with Firebug 1.05, run then change tabs right after. (1.23 KB, text/html)
2007-10-22 22:30 PDT, John J. Barton
no flags Details
jst's attachment 305891 from bug 303821 comment 57 (1.61 KB, patch)
2008-03-03 09:26 PST, timeless
no flags Details | Diff | Splinter Review
my patch (2.45 KB, patch)
2008-03-03 09:59 PST, timeless
jst: review+
mbeltzner: approval1.9+
Details | Diff | Splinter Review
backport (2.44 KB, patch)
2008-03-05 13:48 PST, timeless
samuel.sidler+old: approval1.8.1.13-
dveditz: approval1.8.1.15+
Details | Diff | Splinter Review

Description timeless 2005-02-17 18:22:25 PST
note also bug 282658

Unhandled exception at 0x00e4685e (jsd3250.dll) in mozilla.exe: 0xC0000005:
Access violation reading location 0x00000000.

EAX = 00000000 EBX = 00000001 ECX = 0B6B8D98 EDX = 00E4683D ESI = 0AE48EE8 EDI =
00000000 EIP = 00E4685E ESP = 0012F1D8 EBP = 0012F1E4 EFL = 00200202 

>	jsd3250.dll!jsds_NotifyPendingDeadScripts(JSContext * cx=0x0012f224)  Line
503 + 0x3	C++
 	jsd3250.dll!jsds_GCCallbackProc(JSContext * cx=0x00a6d888, JSGCStatus
status=JSGC_END)  Line 521	C++
 	js3250.dll!js_GC(JSContext * cx=0x00a6d888, unsigned int gcflags=0)  Line 1448	C
 	js3250.dll!js_ForceGC(JSContext * cx=0x00a6d888, unsigned int gcflags=0)  Line
1028 + 0x19	C
 	js3250.dll!JS_GC(JSContext * cx=0x00a6d888)  Line 1747 + 0x8	C
 	js3250.dll!JS_MaybeGC(JSContext * cx=0x00a6d888)  Line 1766 + 0x6	C
 	gklayout.dll!nsJSContext::ScriptEvaluated(int aTerminated=0)  Line 1875 + 0xc	C++
 	gklayout.dll!nsJSContext::ScriptExecuted()  Line 1946	C++
 	xpc3250.dll!AutoScriptEvaluate::~AutoScriptEvaluate()  Line 107	C++
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *
wrapper=0x010778dd, unsigned short methodIndex=55432, const nsXPTMethodInfo *
info=0x0012f350, nsXPTCMiniVariant * nativeParams=0x00000004)  Line 1588 + 0x11	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const
nsXPTMethodInfo * info=0x00a621c0, nsXPTCMiniVariant * params=0x0012f408) 
Line 450	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x091cff70, unsigned
int methodIndex=3, unsigned int * args=0x0012f4c4, unsigned int *
stackBytesToPop=0x0012f4b4)  Line 117 + 0x12	C++
 	xpcom_core.dll!SharedStub()  Line 147	C++
 	xpcom_core.dll!nsObserverService::NotifyObservers(nsISupports *
aSubject=0x0cde2210, const char * aTopic=0x00be1f90, const unsigned short *
someData=0x00000000)  Line 210	C++
 	necko.dll!nsHttpHandler::NotifyObservers(nsIHttpChannel * chan=0x0cde2210,
const char * event=0x00be1f90)  Line 480	C++
 	necko.dll!nsHttpChannel::AsyncOpen(nsIStreamListener * listener=0x0a72fd28,
nsISupports * context=0x00000000)  Line 3123	C++
 	imglib2.dll!imgLoader::LoadImage(nsIURI * aURI=0x0a6e5b28, nsIURI *
aInitialDocumentURI=0x0b31b408, nsIURI * aReferrerURI=0x0b31b408, nsILoadGroup *
aLoadGroup=0x0b59ba10, imgIDecoderObserver * aObserver=0x124aeca0, nsISupports *
aCX=0x025600d0, unsigned int aLoadFlags=0, nsISupports * cacheKey=0x00000000,
imgIRequest * aRequest=0x00000000, imgIRequest * * _retval=0x124aeca4)  Line
510 + 0xc	C++
 	gklayout.dll!nsContentUtils::LoadImage(nsIURI * aURI=0x0a6e5b28, nsIDocument *
aLoadingDocument=0x025600d0, nsIURI * aReferrer=0x0b31b408, imgIDecoderObserver
* aObserver=0x124aeca0, int aLoadFlags=0, imgIRequest * * aRequest=0x124aeca4) 
Line 1768 + 0x29	C++
 	gklayout.dll!nsImageLoadingContent::ImageURIChanged(const nsACString &
aNewURI={...})  Line 481	C++
 	gklayout.dll!nsImageLoadingContent::ImageURIChanged(const nsAString &
aNewURI={...})  Line 411 + 0x14	C++
 	gklayout.dll!nsHTMLImageElement::SetParent(nsIContent * aParent=0x093dd6e8)
 Line 634	C++
 	gklayout.dll!nsGenericElement::AppendChildTo(nsIContent * aKid=0x124aec88, int
aNotify=0, int aDeepSetDocument=0)  Line 2600	C++
 	gklayout.dll!SinkContext::AddLeaf(nsIHTMLContent * aContent=0x124aec88) 
Line 1565	C++
 	gklayout.dll!SinkContext::AddLeaf(const nsIParserNode & aNode={...})  Line
1497	C++
 	gklayout.dll!HTMLContentSink::AddLeaf(const nsIParserNode & aNode={...}) 
Line 3127	C++
 	gkparser.dll!CNavDTD::AddLeaf(const nsIParserNode * aNode=0x0ab3a868)  Line
3774 + 0xd	C++
 	gkparser.dll!CNavDTD::HandleDefaultStartToken(CToken * aToken=0x090bb410,
nsHTMLTag aChildTag=eHTMLTag_a, nsCParserNode * aNode=0x0ab3a868)  Line 1443 +
0x8	C++
 	gkparser.dll!CNavDTD::HandleStartToken(CToken * aToken=0x00000034)  Line
1818 + 0xe	C++
 	gkparser.dll!CNavDTD::HandleToken(CToken * aToken=0x00000034, nsIParser *
aParser=0x0ae1bb28)  Line 1003 + 0xa	C++
 	gkparser.dll!CNavDTD::BuildModel(nsIParser * aParser=0x0ae1bb28, nsITokenizer
* aTokenizer=0x0bdb0520, nsITokenObserver * anObserver=0x00000000,
nsIContentSink * aSink=0x0a76a484)  Line 472 + 0xa	C++
 	gkparser.dll!nsParser::BuildModel()  Line 2032	C++
 	gkparser.dll!nsParser::ResumeParse(int allowIteration=1, int aIsFinalChunk=1,
int aCanInterrupt=1)  Line 1894 + 0x6	C++
 	gkparser.dll!nsParser::ContinueParsing()  Line 1430 + 0xc	C++
 	gkparser.dll!nsParserContinueEvent::HandleEvent(PLEvent * aEvent=0x088c3a70) 
Line 240	C++
 	xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x088c3a70)  Line 693	C
 	xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00a4dce8)  Line
627 + 0x6	C
 	xpcom_core.dll!nsEventQueueImpl::ProcessPendingEvents()  Line 402	C++
 	gkwidget.dll!nsWindow::DispatchPendingEvents()  Line 3721	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=512, unsigned int
wParam=0, long lParam=26542521, long * aRetValue=0x0012fd10)  Line 4092	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x004c038a, unsigned int
msg=512, unsigned int wParam=0, long lParam=38279124)  Line 1355 + 0x10	C++
 	user32.dll!GetDC()  + 0x72	
 	user32.dll!GetDC()  + 0x154	
 	user32.dll!GetWindowLongW()  + 0x127	
 	user32.dll!DispatchMessageW()  + 0xf	
 	gkwidget.dll!nsAppShell::Run()  Line 159	C++
 	appcomps.dll!nsAppStartup::Run()  Line 216	C++
 	mozilla.exe!main1(int argc=2, char * * argv=0x002a4878, nsISupports *
nativeApp=0x0b6b8d98)  Line 1321 + 0x9	C++
 	mozilla.exe!main(int argc=2, char * * argv=0x002a4878)  Line 1813 + 0x13	C++
 	mozilla.exe!WinMain(HINSTANCE__ * __formal=0x00400000, HINSTANCE__ *
__formal=0x00400000, char * args=0x0015235a, HINSTANCE__ * __formal=0x00400000)
 Line 1841 + 0x17	C++
 	mozilla.exe!WinMainCRTStartup()  Line 390 + 0x1b	C
 	kernel32.dll!RegisterWaitForInputIdle()  + 0x49	

-	(DeadScript*)esi	0x0ae48ee8 {links={next=0x14aa9cf8 {next=0x0659eb30
{next=0x061bfa60 prev=0x14aa9cf8 } prev=0x0b6b8d98 {next=0x14aa9cf8
prev=0x0b6ea568 } } prev=0x0b6b8d98 {next=0x14aa9cf8 {next=0x0659eb30
prev=0x0b6b8d98 } prev=0x0b6ea568 {next=0x0b6b8d98 prev=0x06664e68 } } }
jsdc=0x00a53c58 {links={next=0x00e4c010 __jsd_context_list prev=0x00e4c010
__jsd_context_list } inited=1 data=0x00000000 ...} script=0x00000000 }	DeadScript *
|+	links	{next=0x14aa9cf8 {next=0x0659eb30 {next=0x061bfa60 {next=0x0a4239b8
prev=0x0659eb30 } prev=0x14aa9cf8 {next=0x0659eb30 prev=0x0b6b8d98 } }
prev=0x0b6b8d98 {next=0x14aa9cf8 {next=0x0659eb30 prev=0x0b6b8d98 }
prev=0x0b6ea568 {next=0x0b6b8d98 prev=0x06664e68 } } } prev=0x0b6b8d98
{next=0x14aa9cf8 {next=0x0659eb30 {next=0x061bfa60 prev=0x14aa9cf8 }
prev=0x0b6b8d98 {next=0x14aa9cf8 prev=0x0b6ea568 } } prev=0x0b6ea568
{next=0x0b6b8d98 {next=0x14aa9cf8 prev=0x0b6ea568 } prev=0x06664e68
{next=0x0b6ea568 prev=0x0bc4b008 } } } }	PRCListStr
|+	jsdc	0x00a53c58 {links={next=0x00e4c010 __jsd_context_list prev=0x00e4c010
__jsd_context_list } inited=1 data=0x00000000 ...}	JSDContext *
\+	script	0x00000000	jsdIScript *

jsds_NotifyPendingDeadScripts (JSContext *cx)
00E467F8  push        ebp  
00E467F9  mov         ebp,esp 
00E467FB  push        ecx  
    nsCOMPtr<jsdIScriptHook> hook = 0;   
    gJsds->GetScriptHook (getter_AddRefs(hook));
00E467FC  mov         eax,dword ptr [gJsds (0E4C0E4h)] 
00E46801  push        esi  
00E46802  push        edi  
00E46803  xor         edi,edi 
00E46805  mov         dword ptr [hook],edi 
00E46808  mov         esi,dword ptr [eax] 
00E4680A  lea         ecx,[hook] 
00E4680D  call        nsCOMPtr<nsIEventQueue>::StartAssignment (0E45DFFh) 
00E46812  push        eax  
00E46813  push        dword ptr [gJsds (0E4C0E4h)] 
00E46819  call        dword ptr [esi+18h] 

    DeadScript *ds;
    JSRuntime *rt = JS_GetRuntime(cx);
00E4681C  mov         eax,dword ptr [gJsds (0E4C0E4h)] 
00E46821  mov         ecx,dword ptr [eax] 
00E46823  push        edi  
00E46824  push        eax  
00E46825  call        dword ptr [ecx+88h] 
    while (gDeadScripts) {
00E4682B  jmp         jsds_NotifyPendingDeadScripts+77h (0E4686Fh) 
        ds = gDeadScripts;
        if (hook)
00E4682D  mov         eax,dword ptr [hook] 
00E46830  cmp         eax,edi 
00E46832  je          jsds_NotifyPendingDeadScripts+45h (0E4683Dh) 
            /* tell the user this script has been destroyed */
            hook->OnScriptDestroyed (ds->script);
00E46834  push        dword ptr [esi+0Ch] 
00E46837  mov         ecx,dword ptr [eax] 
00E46839  push        eax  
00E4683A  call        dword ptr [ecx+10h] 
        /* get next deleted script */
        gDeadScripts = NS_REINTERPRET_CAST(DeadScript *,
00E4683D  mov         eax,dword ptr [esi] 
        if (gDeadScripts == ds) {
00E4683F  cmp         eax,esi 
00E46841  mov         dword ptr [gDeadScripts (0E4C0E8h)],eax 
00E46846  jne         jsds_NotifyPendingDeadScripts+56h (0E4684Eh) 
            /* last script in the list */
            gDeadScripts = nsnull;
00E46848  mov         dword ptr [gDeadScripts (0E4C0E8h)],edi 
        /* take ourselves out of the circular list */
00E4684E  mov         ecx,dword ptr [esi+4] 
00E46851  mov         dword ptr [ecx],eax 
00E46853  mov         eax,dword ptr [esi] 
00E46855  mov         ecx,dword ptr [esi+4] 
00E46858  mov         dword ptr [eax+4],ecx 
        /* addref came from the FromPtr call in jsds_ScriptHookProc */
00E4685B  mov         eax,dword ptr [esi+0Ch] 
00E4685E  mov         ecx,dword ptr [eax] 
00E46860  push        eax  
00E46861  call        dword ptr [ecx+8] 
        /* free the struct! */
00E46864  push        esi  
00E46865  mov         dword ptr [esi+0Ch],edi 
00E46868  call        dword ptr [__imp__PR_Free (0E491DCh)] 
00E4686E  pop         ecx  
00E4686F  mov         esi,dword ptr [gDeadScripts (0E4C0E8h)] 
00E46875  cmp         esi,edi 
00E46877  jne         jsds_NotifyPendingDeadScripts+35h (0E4682Dh) 

00E46879  mov         eax,dword ptr [gJsds (0E4C0E4h)] 
00E4687E  mov         ecx,dword ptr [eax] 
00E46880  push        edi  
00E46881  push        eax  
00E46882  call        dword ptr [ecx+8Ch] 
00E46888  lea         ecx,[hook] 
00E4688B  call        dword ptr [__imp_nsCOMPtr_base::~nsCOMPtr_base (0E49230h)] 
00E46891  pop         edi  
00E46892  pop         esi  
00E46893  leave            
00E46894  ret              

This is a build based on mozilla1.8a5 with a couple of changes to js for certain
crashers (but none to jsd).

i'm fairly certain i've hit this a couple of times before.
Comment 1 whorfin 2007-04-13 13:08:46 PDT
I think I've hit this twice.  TB30867552Z and TB31164388W
I also think this may be related to Bug 376643.
In both of my crashes, firefox was suffering from that bug's symptoms [100% CPU].  In both crashes I had selected "Exit"; all windows closed, but firefox continued to be pegged at 100% CPU until eventually this crash.  Is it possible that
these pending queued timer events try to fire after the script is dead?
Comment 2 Daniel Veditz [:dveditz] 2007-05-01 16:13:02 PDT
While trying to reproduce the claimed crash associated with bug 379390 (normally I got just a temporary CPU spike/hang) I got this stack. TB31715128 (FF2.0.0.4pre on windows).
Comment 3 whorfin 2007-05-28 15:28:52 PDT
Hit it yet again, just as in my previous report.  TB32552572K
Comment 4 Samuel Sidler (old account; do not CC) 2007-06-04 15:03:05 PDT
This crash seems to be a topcrash in Firefox, which is weird to me because it's filed in the JavaScript Debugger component.

Stack Signature	 jsds_NotifyPendingDeadScripts 3314a509
Product ID	Firefox2
Build ID	2007051502
Trigger Time	2007-06-04 14:18:19.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	jsd3250.dll + (00004caf)
URL visited	
User Comments	
Since Last Crash	7224 sec
Total Uptime	167528 sec
Trigger Reason	Access violation
Source File, Line No.	c:/builds/tinderbox/Fx-Mozilla1.8-release/WINNT_5.2_Depend/mozilla/js/jsd/jsd_xpc.cpp, line 501
Stack Trace 	
jsds_NotifyPendingDeadScripts  [mozilla/js/jsd/jsd_xpc.cpp, line 501]
jsds_GCCallbackProc  [mozilla/js/jsd/jsd_xpc.cpp, line 519]
JS_GC  [mozilla/js/src/jsapi.c, line 1879]
ScopedXPCOMStartup::~ScopedXPCOMStartup  [mozilla/toolkit/xre/nsAppRunner.cpp, line 740]
main  [mozilla/browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x16fd7 (0x7c816fd7)
Comment 5 James Ross 2007-06-04 15:55:30 PDT
Samuel, the Bugzilla "JavaScript Debugger" component covers two items:
 - JSD, the compiled debugging core, which is the jsd3250 module in stacks.
 - Venkman, one of the front-ends for JSD (Firebug being the commonest other).

JSD, being compiled, is shipped with everything (except, sometimes, badly configured Linux distribution builds), and is where the bug (or at least the top of the stack) is.

Due to the way certain SpiderMonkey hooks have to be chained, once JSD has added its GC hook (which it will do as soon as any debugger front end is initialised), it will stay hooked until app shutdown. It is also possible JSD is being turned on during startup, but I cannot recall the exact specifics to check this.
Comment 6 timeless 2007-06-04 23:56:30 PDT
note that firebug is also a jsd consumer and iirc it has an option that enables it to start when firefox launches.

amusingly, i believe that both venkman and firebug can probably enable jsd at launch such that when firefox updates venkman/firebug are incompatible and thus "disabled" by EM, but because of the way the jsd hook registers (xpcom startup category), it will probably not be disabled by the app update :).

but that really isn't particularly relevant. the question is how can script end up null. basically someone needs to figure out if this is a reentrancy issue, a threading/concurrency issue, a lifetime issue, or something else.

most likely this will require someone to read the code very very very carefully (I've tried a couple of times and haven't managed to figure out the problem).
Comment 7 Daniel Veditz [:dveditz] 2007-06-21 10:50:32 PDT
It's not realistic to block the branch on this bug when it's both unconfirmed and assigned to someone who probably isn't actively coding any more.

Did this become a top crash because we changed something in our code recently, or simply because Firebug has gotten popular?
Comment 8 Daniel Veditz [:dveditz] 2007-06-21 11:39:59 PDT
We should add this information to the list of problematic extensions at
Comment 9 timeless 2007-06-21 15:07:07 PDT
dveditz: we probably could wallpaper this if someone wanted to, the wallpaper for that is trivially obvious. the problem is that i can't figure out what's up. it doesn't make sense :(
Comment 10 timeless 2007-06-22 07:59:56 PDT
Created attachment 269381 [details] [diff] [review]

there's no reasonable way for me to test this since i don't have any way to reproduce it (other than general exhaustive use). if i could actually reproduce it, i'd have tried to figure out what was actually wrong and fix that instead...
Comment 11 whorfin 2007-06-24 15:44:36 PDT
I believe there is indeed a way to reproduce this behavior, apologies if i
was not more clear in my first cross-referenced report of this bug.

See Bug 376643 [marked resolved but that's not true for any current build such as firefox].  Make sure
javascript is enabled.  In several tabs or windows, load several copies of
the script referenced by that bug.  Open a bunch of other tabs and windows to elsewhere for good measure, some of them to other sites with javascript code using setInterval, such as scrollers.  If you really want to quickly trigger
this bug, make a local copy of the javascript and change the interval to
something even faster, like 100 or [yike!] 10 milliseconds.  I say yike because
Bug 376643 will really hose firefox with such small delays.  In any event,
having many copies of the script running in separate tabs/windows, proceed to
either kill -STOP or pssuspend the process [see Bug 376643 for details].
Wait a good long while, unless you've made a local copy with short delay,
in which case a few minutes should suffice.  Then kill -CONT or otherwise resume the process.  You should see that your CPU is hammered by firefox.
As soon as you can, select "Exit" from the File menu.  You should observe that your CPU is still hammered, and the windows eventually all close, but your CPU remains hammered.  After some time, firefox will crash with a talkback ID which will resolve to this error.
Comment 12 timeless 2007-06-24 16:17:53 PDT
then by all means, please build --enable-debugger-info-modules and add some tracing to figure out what's happening to ds->script.

sorry, my current work does not extend anywhere near this area. but people on irc will gladly talk you through instrumenting this code.
Comment 13 whorfin 2007-06-24 16:57:56 PDT
Sorry, i'm even less involved here, just volunteering information
as i have consistently encountered this bug while contributing to the
identification and fixing of the "100% CPU upon resume" bug.
Comment 14 Alex Vincent [:WeirdAl] 2007-09-02 14:24:33 PDT
whorfin, is this reproducible with a current trunk nightly?
Comment 15 whorfin 2007-09-05 19:25:26 PDT
You're free to follow the reproduction instructions above on a trunk if you'd like.  For what it's worth, it just happened to me again on the current release; see TB35632506Y.
Comment 16 John J. Barton 2007-10-22 22:30:02 PDT
Created attachment 285846 [details]
Test case with Firebug 1.05, run then change tabs right after.

I see this stack trace from Firebug in FF2 once in a while.  In the process of developing a profiling test case for performance enhancements for Firebug 1.2, I ran the test in Firebug 1.05. I crashed three times out of maybe 6. It seems to help (that is crash more ;-) if I change tabs soon after the test runs.
FF + Firebug 1.05 ( version) + html attached + change tabs.  TB 37254658, 37254423, 37254216
Comment 17 John J. Barton 2007-10-22 22:34:49 PDT
One more interesting point: the performance test here creates lots of functions in eval() (and new Function()). The pageads/adsense crash happens right after lots of functions in an eval().
Comment 18 timeless 2007-10-23 00:49:44 PDT could you possibly build and try w/ my patch? if you have this reproducable, it should be fairly easy for you to decide whether it fixes the problem.

If it does fix it, you should try sticking some printfs into the referenced functions, i suppose.
Comment 19 Mike Schroepfer 2007-11-09 13:41:55 PST
Since this must have shipped in FF2/FF1.5 not marking as blocking for FF3/Gecko1.9.  If you think it should re-nom.  If patch comes along we'd obviously consider...
Comment 20 Samuel Sidler (old account; do not CC) 2007-11-09 13:47:05 PST
This may have shipped in FF2/1.5 but it's also a topcrash and I think we should fix it.

Dan, do you have time to review this? Is there someone else who might?
Comment 21 John J. Barton 2007-11-09 18:45:30 PST
I've never hit this one on FF3.  Doesn't prove much, but I've also not hit a cluster of bugs described in 400532 and 400618.  Its my hunch that these are all related to a jsd-gc issue which was uncovered by the discovery of AJAX (many more evals) and Firebug (many more jsd users).  They all have the character of multi-thread bugs, being unreliable in place and time. I suggest looking at 400532 first because it is the most reproducible and it can be traced down to a single kind of call if not the same one each time.

Comment 22 Daniel Veditz [:dveditz] 2007-11-11 11:19:14 PST
Comment on attachment 269381 [details] [diff] [review]

Clearing sr-request, we'll need some sort of module-owner/peer review on this.

r- because I don't think this solves anything. There is no way script can be null, and if you're positing memory corruption then I'd prefer a safe null-dereference over taking our chances with a double-free

I didn't see any of the talkbacks point at this line, in fact. The large majority of them were crashing on line 501, PR_REMOVE_LINK(&ds->links);

A few crashed on line 471, gJsds->GetScriptHook(getter_AddRefs(hook));
Comment 23 Henrik Skupin (:whimboo) 2007-11-21 03:01:26 PST
I got the same crash some minutes ago while Firefox was closed to apply the todays update. Build ident is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071120 BonEcho/ ID:2007112004. I've also Firebug installed.

The Talkback id is TB38298366W.

Shouldn't the bug be confirmed?
Comment 24 Wayne Mery (:wsmwk, NI for questions) 2007-11-21 06:14:54 PST
#4 crasher for
no crashes (well, one for 2007080200 build) on trunk crash-stats.
Comment 25 Peter Janes 2008-01-05 08:55:33 PST
This (or something very similar) also happens on Linux, build ID "Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20071127 Firefox/", every time I shut down the browser (see TB39870148H, TB39772035E, TB39758026X).  I do have Firebug 1.05 installed; when I exited the next session after I disabled it to look into bug 366509 the browser didn't crash.

(I guess this just confirms everything that others have reported, except to add that it's happening on Linux too.)
Comment 26 timeless 2008-01-23 00:35:23 PST
re Comment 22:
> A few crashed on line 471, gJsds->GetScriptHook(getter_AddRefs(hook));

that's bug 411249
Comment 27 timeless 2008-01-23 00:53:46 PST
btw, bug 379390 comment 8 has the closest thing i see to smoke. I'll have to think about it a bit more, but it might actually be a useful skid mark, here's the part that interests me:
jsds_NotifyPendingDeadScripts  [mozilla/js/jsd/jsd_xpc.cpp, line 501]
jsds_GCCallbackProc  [mozilla/js/jsd/jsd_xpc.cpp, line 519]
js_NewGCThing  [mozilla/js/src/jsgc.c, line 1420]
js_NewString  [mozilla/js/src/jsstr.c, line 2442]
js_NewStringCopyZ  [mozilla/js/src/jsstr.c, line 2576]
JS_NewUCStringCopyZ  [mozilla/js/src/jsapi.c, line 4497]

I'm wondering if something got dead (more on a weekend)
Comment 28 Justin Dolske [:Dolske] 2008-03-02 01:18:28 PST
J. Barton: The test case you post in comment 16 doesn't seem functional; it needs a runner.js and functions [eg, test()] it presumably contains. Can you fix that, or point me to where this came from (almost looks like one of our JS tests?)?

Not sure how else to test if this exists on trunk or not, though your comment 21 makes it sound like it probably doesn't?
Comment 29 John J. Barton 2008-03-02 09:39:49 PST
The test case in comment 16 uses
However I can't swear that this file is unchanged since I tried it back in Oct. 

The code is modified from John Resig's runner.js, see

I've not seen this on FF3.

Before firebug-1.1.0b12 we did not call when we should. Since activation in firebug depends on the tab, its possible that tab switching and failure to call could be involved.
Comment 30 timeless 2008-03-03 09:26:55 PST
Created attachment 307058 [details] [diff] [review]
jst's attachment 305891 [details] [diff] [review] from bug 303821 comment 57

these are the only correct/relevant hunks. I've reordered the comment /remove-link / deadscripts lines, changed the comment(s).

I have an alternate patch which I'll post shortly.
Comment 31 timeless 2008-03-03 09:59:14 PST
Created attachment 307066 [details] [diff] [review]
my patch

i think a lock may still be needed because i don't think the operations here are truly thread safe. (And I don't like the Pause/Unpause stuff, I think it's bogus. If it's trying to avoid thread problems, it fails miserably, as it's amazingly easy to lose the races it's creating.)

basically, I worry that the else case in jsds_ScriptHookProc gGCStatus == JSGC_END could conceivably happen on two threads. That might not actually be possible, if the only way to reach it is from the GC thread.
Comment 32 Mike Beltzner [:beltzner, not reading bugmail] 2008-03-05 08:31:45 PST
Comment on attachment 307066 [details] [diff] [review]
my patch

Comment 33 timeless 2008-03-05 13:37:13 PST
Comment on attachment 307066 [details] [diff] [review]
my patch

mozilla/js/jsd/jsd_xpc.cpp 	1.87
Comment 34 Samuel Sidler (old account; do not CC) 2008-03-05 13:41:36 PST
timeless, does this patch apply on branch as well? This is a topcrasher on branch, so it'd be great to get something there as well.
Comment 35 timeless 2008-03-05 13:48:26 PST
Created attachment 307571 [details] [diff] [review]

there's only one difference (reinterpret_cast)
Comment 36 Samuel Sidler (old account; do not CC) 2008-03-07 11:11:23 PST
Comment on attachment 307571 [details] [diff] [review]

We're too late in the cycle to take this now and want some more trunk baking before we take this on the branch. Minusing for, but nominating for
Comment 37 timeless 2008-03-31 21:15:10 PDT
*** Bug 282658 has been marked as a duplicate of this bug. ***
Comment 38 Daniel Veditz [:dveditz] 2008-04-21 11:11:27 PDT
Comment on attachment 307571 [details] [diff] [review]

approved for, a=dveditz for release-drivers
Comment 39 Daniel Veditz [:dveditz] 2008-05-31 10:19:47 PDT
Checked fix into the 1.8 branch
Comment 40 Al Billings [:abillings] 2008-06-10 13:29:30 PDT
I can't validate the crash in with Firebug installed.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: Gecko/2008040413 Firefox/
Comment 41 timeless 2008-06-18 10:52:01 PDT
*** Bug 438691 has been marked as a duplicate of this bug. ***
Comment 42 Daniel Veditz [:dveditz] 2008-07-09 22:04:38 PDT
verifying based on talkback: this dropped from #20 topcrash in Firefox to #182 in

Note You need to log in before you can comment on or make changes to this bug.