reports have been coming in about crashing when using the Linkification extension. problem is that we need reproducible test steps, as some people cannot repro the crash.

I cannot seem to crash (so far) using the following builds: 2005040819-1.0.3 (linux) 2005041107-1.0.3 (linux)

Pushing onto our radar. We'll set blocking once we get closer to finding the cause of the crashes.

My talkback ID's: TB4956550E, TB4956471Z, TB4956364W, TB4955681M, TB4955647Q, TB4955419Z, TB4955396Z, TB4955142X, TB4955079G, TB4954756Q, TB4954566Y

The ID's in my previous post were with Linkification 0.9.19 This is with 0.9.20 TB5016308Y 0 crashes when Linkification has been uninstalled and 0 crashes with other 1.0.3 release candidates using Linkification. To cause crash I open multiple tabs in row and click links on them while some tabs are still loading. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050408 Firefox/1.0.3

The ID's: TB5016721H TB5016686X TB5016530X TB5016302G My FF version: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050410 Firefox/1.0.3(In reply to comment #0)

js_LinkFunctionObject [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsfun.c, line 1973] XPC_WN_JSOp_Safe_GetProperty [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1155] js_Interpret [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 2823] js_Invoke [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 966] nsXPCWrappedJSClass::CallMethod [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1339] nsXPCWrappedJS::CallMethod [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 450] SharedStub [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] nsEventListenerManager::HandleEventSubType [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1436] nsEventListenerManager::HandleEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1516] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 927] nsXULDocument::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1257] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2823] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleChromeEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 3988] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 916] DocumentViewerImpl::LoadComplete [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocumentViewer.cpp, line 917] nsDocShell::EndPageLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4602] nsWebShell::EndPageLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp, line 760] nsDocShell::OnStateChange [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4536] nsDocLoaderImpl::FireOnStateChange [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 1252] nsDocLoaderImpl::doStopDocumentLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 873] nsDocLoaderImpl::OnStopRequest [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 701] nsLoadGroup::RemoveRequest [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 695] imgRequestProxy::RemoveFromLoadGroup [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/modules/libpr0n/src/imgRequestProxy.cpp, line 161] imgRequestProxy::OnStopRequest [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/modules/libpr0n/src/imgRequestProxy.cpp, line 448] nsInputStreamPump::OnStateStop [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 499] http://talkback-reports.mozilla.org/talkback/quicksearch.jsp?search=2&type=iid&id=4956550

also js_GetSlotThreadSafe [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jslock.c, line 554] JS_GetPrivate [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c, line 1999] XPC_WN_JSOp_Safe_GetProperty [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1155] js_Interpret [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 2823] js_Invoke [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c, line 966] nsXPCWrappedJSClass::CallMethod [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1339] nsXPCWrappedJS::CallMethod [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 450] SharedStub [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147] nsEventListenerManager::HandleEventSubType [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1436] nsEventListenerManager::HandleEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1516] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 927] nsXULDocument::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp, line 1257] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2823] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2821] nsXULElement::HandleChromeEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 3988] GlobalWindowImpl::HandleDOMEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 916] DocumentViewerImpl::LoadComplete [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocumentViewer.cpp, line 917] nsDocShell::EndPageLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4602] nsWebShell::EndPageLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp, line 760] nsDocShell::OnStateChange [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp, line 4536] nsDocLoaderImpl::FireOnStateChange [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 1252] nsDocLoaderImpl::doStopDocumentLoad [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 873] nsDocLoaderImpl::OnStopRequest [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp, line 701] nsLoadGroup::RemoveRequest [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp, line 695] HandleImagePLEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsImageLoadingContent.cpp, line 582] PL_HandleEvent [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c, line 674] 0x778b0c24 NS_HSV2RGB [d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSColorUtils.cpp, line 299] 0x8b2175a6

(In reply to comment #3) > My talkback ID's: > TB4956550E, TB4956471Z, TB4956364W, TB4955681M, TB4955647Q, TB4955419Z, > TB4955396Z, TB4955142X, TB4955079G, TB4954756Q, TB4954566Y Did you have any other extensions installed besides Linkification?

(In reply to comment #8) > > Did you have any other extensions installed besides Linkification? Auto Copy, Adblock, FLST, BBCode, BugMeNot

Talkback ID's: TB5024359G TB5024275Z Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050409 Firefox/1.0.3

Crashes happen also when only one tab open. Sorry, can't give any reproducable clickpath because crashes seem pretty random. Happens mostly when browsing different web-forums but I think that's because they have lots of links. :) Also uninstalling all the other extensions didn't help.

Still crashes with: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050411 Firefox/1.0.3 ID: TB5039735Q

For those crashing with this extension (and this extension alone) against today's nightly, could you add your Linkification configuration as a comment in this bug as well?

This fixes a crash in the recently added code in xpconnect, and I bet it's this crash. Brendan says r+sr+a=brendan.

Fixed on branches.

Moving to Core (this affects Suite, too).

blocking1.7.7+, blocking-aviary1.0.3+ Clearing blocking-aviary1.1 flag.

Comment on attachment 180534 [details] [diff] [review] Fix. Prevent function object from being collected while cloning it. Retroactively adding a=chase for branches.

Comment on attachment 180534 [details] [diff] [review] Fix. Prevent function object from being collected while cloning it. Moving this bug from Firefox/Extensions to Core/XPConnect caused jst's review+ to be lost, though his superreview+ was kept.

TB5059822W Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050412 Firefox/1.0.3 Only crash i had so far, looks almost fixed :)

Comment on attachment 180596 [details] [diff] [review] Also prevent function clone from being collected, and fix similar problem in nsWindowWatcher's window.argument handling >- // Call the getter function if the member is an attribute >- if(member->IsAttribute()) > { >- jsid id; >- if(!JS_ValueToId(cx, idval, &id)) >- return JS_FALSE; >+ jsval funval = OBJECT_TO_JSVAL(funobj); Just wondering if the extra block scope helps here -- doesn't it end right where the containing block ends? Could minimize the patch if so. >@@ -443,28 +445,33 @@ NS_IMETHODIMP > nsWindowWatcher::OpenWindow(nsIDOMWindow *aParent, > const char *aUrl, > const char *aName, > const char *aFeatures, > nsISupports *aArguments, > nsIDOMWindow **_retval) > { > PRUint32 argc; > jsval *argv = nsnull; >+ JSContext *cx; >+ void *markp; Canonical name is just mark (markp is the pointer to mark out param name in js-land). r/sr/a=me, thanks for fixing all this. /be

(In reply to comment #23) > Just wondering if the extra block scope helps here -- doesn't it end right > where the containing block ends? Could minimize the patch if so. It's there only because you can't have two AUTO_MARK_JSVAL's in the same scope. I'll comment on that.

Last change landed on the aviary and 1.7 branches.

Comment on attachment 180596 [details] [diff] [review] Also prevent function clone from being collected, and fix similar problem in nsWindowWatcher's window.argument handling So I can crash reliably with TOO_MUCH_GC defined, and I think it's because of this patch. The steps to reproduce are simply to launch with a URL on the command line: ./firefox -P 1.0 http://www.netflix.com/ (where 1.0 is a profile name) I crash here: #5 <signal handler called> #6 0xb7c30ca6 in js_GetGCThingFlags (thing=0x5b) at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:218 #7 0xb7c3147f in js_MarkGCThing (cx=0x8185230, thing=0xdadadad8, arg=0x0) at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:833 #8 0xb7c31d38 in js_GC (cx=0x8185230, gcflags=1) at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:1288 #9 0xb7c322df in js_AllocGCThing (cx=0x8185230, flags=1) at /builds/aviary1.0.1/mozilla/js/src/jsgc.c:463 #10 0xb7c6ed21 in js_NewString (cx=0x8185230, chars=0x5b, length=23, gcflag=91) at /builds/aviary1.0.1/mozilla/js/src/jsstr.c:2450 #11 0xb7c6ee06 in js_NewStringCopyN (cx=0x8185230, s=0x820c2a0, n=23, gcflag=0) at /builds/aviary1.0.1/mozilla/js/src/jsstr.c:2561 #12 0xb7c0d4ad in JS_NewUCStringCopyN (cx=0x8185230, s=0x820c2a0, n=23) at /builds/aviary1.0.1/mozilla/js/src/jsapi.c:3838 #13 0xb74c053b in nsWindowWatcher::AddSupportsTojsvals (aArg=0xbfffe7a0, cx=0x8185230, aArgv=0x826f200) at /builds/aviary1.0.1/mozilla/embedding/components/windowwatcher/src/nsWindowWatc her.cpp:1841 #14 0xb74c0d90 in nsWindowWatcher::ConvertSupportsTojsvals (aWindow=0x0, aArgs=0x820c390, aArgc=0xbfffe9ac, aArgv=0xbfffe9b0, aUsedContext=0x5b, aMarkp=0xbfffe9b8) at /builds/aviary1.0.1/mozilla/embedding/components/windowwatcher/src/nsWindowWatc her.cpp:1759 In frame 8, acx == cx, sh == acx->stackHeaders, sh->nslots is 1, and sh->down is null. (In other words, this is the only JSStackHeader in the stack, which I guess shouldn't be too surprising.) It seems like uninitialized memory. I'm not sure what the protocol for js_AllocStack is (I couldn't find any documentation), but it seems like either js_AllocStack or its caller should be responsible for JSVAL_VOID-filling the memory in the stack in case the caller allocates GC-things before filling in all the jsval* that js_AllocStack allocated. The following patch to nsWindowWatcher.cpp fixes my crash: jsval *argv = js_AllocStack(cx, argCount, aMarkp); NS_ENSURE_TRUE(argv, NS_ERROR_OUT_OF_MEMORY); + // We're going to allocate GC things before we fill in |argv| for + // real, so fill it with JSVAL_VOID so that, if the GC runs, it won't + // read uninitialized memory. + for (jsval *vp = argv, *vp_end = argv + argCount; vp < vp_end; ++vp) + *vp = JSVAL_VOID; + if (argsArray) But based on my understanding of js_AllocStack so far, I wonder if other callers, like find_replen in jsstr.c, could also be problematic. That said, I don't yet understand what this code in js_AllocStack is supposed to do: fp = cx->fp; if (fp && fp->script && fp->spbase) { #ifdef DEBUG jsuword depthdiff = fp->script->depth * sizeof(jsval); JS_ASSERT(JS_UPTRDIFF(fp->sp, fp->spbase) <= depthdiff); JS_ASSERT(JS_UPTRDIFF(*markp, fp->spbase) >= depthdiff); #endif end = fp->spbase + fp->script->depth; for (vp = fp->sp; vp < end; vp++) *vp = JSVAL_VOID; } so I really can't tell when there's already JSVAL_VOID-filling should already be happening.

dbaron, thanks for finding this old bug. It's a bug in js_AllocStack -- but not in the JSVAL_VOID-storing code that's there (that code is filling any gap between current top of stack and end of allocated space for this frame's operands). The bug is that js_AllocStack doesn't clear new space that it returns. Bug 290476 filed. /be

brendan's working on the xpconnect merge

a=brendan over IRC

xpconnect changes will be done as part of bug 281988, resolving fixed.