Closed
Bug 282660
Opened 19 years ago
Closed 16 years ago
Crash [@ jsds_NotifyPendingDeadScripts] ds->script is null
Categories
(Other Applications Graveyard :: Venkman JS Debugger, defect)
Other Applications Graveyard
Venkman JS Debugger
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9beta5
People
(Reporter: timeless, Assigned: timeless)
References
()
Details
(Keywords: crash, topcrash, verified1.8.1.15)
Crash Data
Attachments
(4 files, 1 obsolete file)
1.23 KB,
text/html
|
Details | |
1.61 KB,
patch
|
Details | Diff | Splinter Review | |
2.45 KB,
patch
|
jst
:
review+
beltzner
:
approval1.9+
|
Details | Diff | Splinter Review |
2.44 KB,
patch
|
samuel.sidler+old
:
approval1.8.1.13-
dveditz
:
approval1.8.1.15+
timeless
:
approval1.8.0.next?
|
Details | Diff | Splinter Review |
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 * JS_STATIC_DLL_CALLBACK (void) 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; #ifdef CAUTIOUS_SCRIPTHOOK JSRuntime *rt = JS_GetRuntime(cx); #endif gJsds->Pause(nsnull); 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 */ #ifdef CAUTIOUS_SCRIPTHOOK JS_UNKEEP_ATOMS(rt); #endif 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] #ifdef CAUTIOUS_SCRIPTHOOK JS_KEEP_ATOMS(rt); #endif } /* get next deleted script */ gDeadScripts = NS_REINTERPRET_CAST(DeadScript *, PR_NEXT_LINK(&ds->links)); 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 */ PR_REMOVE_LINK(&ds->links); 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 */ NS_RELEASE(ds->script); 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! */ PR_Free(ds); 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) } gJsds->UnPause(nsnull); 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.
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•17 years ago
|
||
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 4•17 years ago
|
||
This crash seems to be a topcrash in Firefox 2.0.0.4, 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)
Keywords: topcrash
Updated•17 years ago
|
Flags: blocking1.8.1.5?
Comment 5•17 years ago
|
||
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.
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•17 years ago
|
||
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?
Flags: blocking1.9?
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5-
Comment 8•17 years ago
|
||
We should add this information to the list of problematic extensions at mozillazine.org
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 :(
Assignee | ||
Comment 10•17 years ago
|
||
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...
Attachment #269381 -
Flags: superreview?(dveditz)
Attachment #269381 -
Flags: review?(dveditz)
Comment 11•17 years ago
|
||
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 2.0.0.4]. 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.
Assignee | ||
Comment 12•17 years ago
|
||
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•17 years ago
|
||
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•17 years ago
|
||
whorfin, is this reproducible with a current trunk nightly?
Comment 15•17 years ago
|
||
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•17 years ago
|
||
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 2.0.0.8 + Firebug 1.05 (getfirebug.com version) + html attached + change tabs. TB 37254658, 37254423, 37254216
Comment 17•17 years ago
|
||
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().
Assignee | ||
Comment 18•17 years ago
|
||
johnjbarton@johnjbarton.com: 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•17 years ago
|
||
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...
Flags: blocking1.9? → blocking1.9-
Comment 20•17 years ago
|
||
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•17 years ago
|
||
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. John.
Comment 22•17 years ago
|
||
Comment on attachment 269381 [details] [diff] [review] wallpaper 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));
Attachment #269381 -
Flags: superreview?(dveditz)
Attachment #269381 -
Flags: review?(dveditz)
Attachment #269381 -
Flags: review-
Comment 23•17 years ago
|
||
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:1.8.1.10pre) Gecko/20071120 BonEcho/2.0.0.10pre ID:2007112004. I've also Firebug installed. The Talkback id is TB38298366W. Shouldn't the bug be confirmed?
Comment 24•17 years ago
|
||
#4 crasher for 2.0.0.9. no crashes (well, one for 2007080200 build) on trunk crash-stats.
Comment 25•17 years ago
|
||
This (or something very similar) also happens on Linux, build ID "Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11", 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.)
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
OS: Windows 2000 → All
Hardware: PC → All
Version: Trunk → 1.8 Branch
Assignee | ||
Comment 26•17 years ago
|
||
re Comment 22: > A few crashed on line 471, gJsds->GetScriptHook(getter_AddRefs(hook)); that's bug 411249
Assignee | ||
Comment 27•17 years ago
|
||
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] PR_REMOVE_LINK(&ds->links); 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)
Updated•16 years ago
|
Whiteboard: [firebug-p1]
Comment 28•16 years ago
|
||
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?
Whiteboard: [firebug-p1] → [firebug-p?]
Comment 29•16 years ago
|
||
The test case in comment 16 uses https://fbug.googlecode.com/svn/branches/performance/runner.js 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 https://fbug.googlecode.com/svn/branches/performance/core-eval.html. I've not seen this on FF3. Before firebug-1.1.0b12 we did not call jsd.off() when we should. Since activation in firebug depends on the tab, its possible that tab switching and failure to call jsd.off() could be involved.
Assignee | ||
Comment 30•16 years ago
|
||
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.
Attachment #269381 -
Attachment is obsolete: true
Assignee | ||
Comment 31•16 years ago
|
||
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.
Attachment #307066 -
Flags: review?(jst)
Attachment #307066 -
Flags: review?(caillon)
Attachment #307066 -
Flags: review?
Updated•16 years ago
|
Attachment #307066 -
Flags: review?(jst) → review+
Attachment #307066 -
Flags: review?(caillon)
Attachment #307066 -
Flags: approval1.9b4?
Attachment #307066 -
Flags: approval1.9?
Updated•16 years ago
|
Attachment #307066 -
Flags: approval1.9b4?
Updated•16 years ago
|
Flags: blocking1.9?
Comment 32•16 years ago
|
||
Comment on attachment 307066 [details] [diff] [review] my patch a1.9=beltzner
Attachment #307066 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 33•16 years ago
|
||
Comment on attachment 307066 [details] [diff] [review] my patch mozilla/js/jsd/jsd_xpc.cpp 1.87
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 34•16 years ago
|
||
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.
Flags: blocking1.8.1.14?
Updated•16 years ago
|
Whiteboard: [firebug-p?]
Target Milestone: --- → mozilla1.9beta5
Version: 1.8 Branch → Trunk
Assignee | ||
Comment 35•16 years ago
|
||
there's only one difference (reinterpret_cast)
Attachment #307571 -
Flags: approval1.8.1.13?
Attachment #307571 -
Flags: approval1.8.0.15?
Updated•16 years ago
|
Keywords: helpwanted
Comment 36•16 years ago
|
||
Comment on attachment 307571 [details] [diff] [review] backport 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 1.8.1.13, but nominating for 1.8.1.14.
Attachment #307571 -
Flags: approval1.8.1.14?
Attachment #307571 -
Flags: approval1.8.1.13?
Attachment #307571 -
Flags: approval1.8.1.13-
Updated•16 years ago
|
Flags: blocking1.8.1.14?
Updated•16 years ago
|
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.15?
Updated•16 years ago
|
Flags: blocking1.8.1.15? → blocking1.8.1.15+
Comment 38•16 years ago
|
||
Comment on attachment 307571 [details] [diff] [review] backport approved for 1.8.1.15, a=dveditz for release-drivers
Attachment #307571 -
Flags: approval1.8.1.15? → approval1.8.1.15+
Comment 40•16 years ago
|
||
I can't validate the crash in 2.0.0.14 with Firebug installed. Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/2008040413 Firefox/2.0.0.14
Comment 42•16 years ago
|
||
verifying based on talkback: this dropped from #20 topcrash in Firefox 2.0.0.14 to #182 in 2.0.0.15
Keywords: fixed1.8.1.15 → verified1.8.1.15
Updated•13 years ago
|
Crash Signature: [@ jsds_NotifyPendingDeadScripts]
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•