Closed Bug 53123 Opened 25 years ago Closed 24 years ago

crash when smart downloading a zip file; any file on winNT; crash M09 [@ js_MarkGCThing, @ gc_find_flags]

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: brendan)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [nsbeta3++][rtm+] ONE LINE FIX READY TO LAND)

Crash Data

Attachments

(6 files)

interesting stack
2.26 KB, text/plain
Details
mscott's mimeTypes.rdf, which helped me reproduce the crash
3.30 KB, patch
Details | Diff | Splinter Review
proposed fix to nsUnknownContentTypeHandler.cpp, plus bonus fix in JS_PushArguments*
2.60 KB, patch
Details | Diff | Splinter Review
realloc crash stack
5.10 KB, text/plain
Details
proposed fix
621 bytes, patch
Details | Diff | Splinter Review
final proposed fix (handles unbalanced stack after error)
626 bytes, patch
Details | Diff | Splinter Review
this occurs on both mac os 9.0 and winnt using 2000.09.18.08/5 opt comm bits. unable to repro on linux since this dialog no longer seems to appear (now always uses the old unknown file type dialog). not sure if this should go to networking or helper apps (xp apps). to repro: 1. go to http://www.mozilla.org/ 2. scroll down to the Nightly Builds section. 3. click the Windows link, which points to http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip result: the smart downloading dialog appears, background downloading starts...but after 1-2 sec, the browser crashes. unable to get a talkback report on winnt :(, but here's one for mac: js_MarkGCThing() [jsgc.c, line 742] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] js_MarkGCThing() [jsgc.c, line 801] gc_root_marker() [jsgc.c, line 824] JS_HashTableEnumerateEntries() [jshash.c, line 364] js_GC() [jsgc.c, line 1054] js_ForceGC() [jsgc.c, line 870] JS_GC() [jsapi.c, line 1523] JS_MaybeGC() [jsapi.c, line 1542] DOM_DLL + 0x10084 (0x0586eea4) nsXPCWrappedJSClass::CallMethod() [xpcwrappedjsclass.cpp, line 1177] nsXPCWrappedJS::CallMethod() [xpcwrappedjs.cpp, line 318] PrepareAndDispatch() [xptcstubs_mac.cpp, line 183] CODE.6 nsBrowserInstance::OnStatusChange() [nsBrowserInstance.cpp, line 1960] nsDocLoaderImpl::FireOnStatusChange() [nsDocLoader.cpp, line 1299] nsDocLoaderImpl::OnStatus() [nsDocLoader.cpp, line 1117] CODE.10 XPTC_InvokeByIndex() [xptcinvoke_mac.cpp, line 129] EventHandler() [nsProxyEvent.cpp, line 506] nsProxyObject::Post() [nsProxyEvent.cpp, line 449] nsProxyEventObject::CallMethod() [nsProxyEventObject.cpp, line 429] PrepareAndDispatch() [xptcstubs_mac.cpp, line 183] CODE.6
this is a regression...hopefully to be fixed by beta3, heh. another observation, re: winNT: it seems that i crash no matter which of the file links i click in the Nightly Builds section --Windows, Macintosh, Linux-- the browser on winNT always crashes a second or two after background saving starts. if someone could get a stacktrace for win32, that'd be great! now, i seemed to have lost track of a bug (unless it doesn't exist yet) where i cannot access the smart downloading dialog *at all on linux*. anyone know? then again, it could be a recent regression... ;-P
Keywords: crash, nsbeta3, regression, stackneeded
Summary: crash when smart downloading a zip file → crash when smart downloading a zip file; any file on winNT
This actually works for me on win2k with 2000091805. The background download completes and I can bring up winzip to view. But it does crash as described for me on Mac with 2000091808. (On linux, it brings up the other/old dialog).
Drat, I can't get this crash to happen on my windows and mac boxes using 9/18 builds. I wonder if I have a helper app installed or something that sairuh doesn't.
still occurs with today's 2000.09.19.05 opt comm bits... unfortunately, cannot specifcally remember offhand which items i installed other than the basic components (i do remove net2phone and aol art, tho'). i'll reinstall and get back to ya on that... however, with today's winnt bits, i finally did get a talkback stack: Incident ID 17681923 Trigger Time 2000-09-19 14:14:47 Email Address sairuh@netscape.com User Comments bug 53123 Build ID 2000091909 Product ID Netscape6 Platform ID Win32 Stack Trace gc_find_flags [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 215] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 721] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_Mark [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 3110] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] gc_root_marker [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 850] JS_HashTableEnumerateEntries [d:\builds\seamonkey\mozilla\js\src\jshash.c, line 365] js_GC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 1060] js_ForceGC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 872] JS_GC [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1531] JS_MaybeGC [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1551] DoPostScriptEvaluated [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 70] nsXPCWrappedJSClass::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1180] nsXPCWrappedJS::CallMethod [d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 319] PrepareAndDispatch [d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, line 102] SharedStub [d:\builds\s
Keywords: stackneeded
latest discovery: when i used the classic skin on winNT, i don't get a crash! seems that this is will only occur in the modern skin on winNT. alas, the crash occurs regardless of skin on Mac. fwiw, i did a custom installation of the following components: navigator mail instant messenger spellchecker sun java2 talkback flash all the language packs hp printer plugin classic skin i made a point of *not* including net2phone or the aol art extensions.
Hmmm...I'm actually using the modern skin too. I also do a custmoize install without net2phone and without the AOL ART stuff. So that must not be the difference.
another data point: while this still occurs with my winNT box at work (using the commercial bits), i cannot reproduce this on a win98 box running mozilla (also modern) 2000.09.19.09. weird.
Adding topcrash keyword, this is a topcrasher according to talkback data [@ js_MarkGCThing]. Below are some talkback entries. The last link in each entry shows you just the stack trace, and the one above it takes you to the entire talkback incident if you need to look deeper. I have also included a stacktrace from a recent crash: js_MarkGCThing 9842bc7d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 741 Build: 2000091508 CrashDate: 2000-09-18 UptimeMinutes: 76 Total: 76 OS: Windows NT 4.0 build 1381 URL: http://www.mozilla.org Comment: I was selecting a directory in which to save the latest nightly build of Mozilla. I want up one level in the directory hierarchy without a problem. When I went up a second level Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17617908 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17617908 js_MarkGCThing() 281758dd jsgc.c line 742 Build: 2000091808 CrashDate: 2000-09-18 UptimeMinutes: 149 Total: 190 OS: MacOS version 9.0 URL: smart-zip Comment: smart-zip Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17623432 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17623432 js_MarkGCThing eaf1edec http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 721 Build: 2000091806 CrashDate: 2000-09-19 UptimeMinutes: 18 Total: 251 OS: Windows 98 4.10 build 67766222 URL: Comment: Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17663539 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17663539 js_MarkGCThing 9842bc7d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 721 Build: 2000091806 CrashDate: 2000-09-18 UptimeMinutes: 0 Total: 233 OS: Windows 98 4.10 build 67766222 URL: Comment: Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17640841 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17640841 js_MarkGCThing 0348b0b1 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 721 Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 6 Total: 7 OS: Windows 98 4.10 build 67766222 URL: law.mcom.com/download.html Comment: Clicked on http link to big.xxx (32M file). Got Downloading... dialog Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17678338 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17678338 js_MarkGCThing 15b66734 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 721 Build: 2000091806 CrashDate: 2000-09-19 UptimeMinutes: 60 Total: 60 OS: Windows 98 4.10 build 67766222 URL: Comment: forumzilla.... downloading the zip file option came up to open using winzip and crash dialog before I could even select.. Stacktrace: http://climate/reports/incidenttemplate.cfm?bbid=17681515 http://climate/reports/stackcommentemail.cfm?dynamicBBID=17681515 Incident ID 17681515 js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 721] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_Mark [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 3068] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] gc_root_marker [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 850] JS_HashTableEnumerateEntries [d:\builds\seamonkey\mozilla\js\src\jshash.c, line 365] js_GC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 1060] js_ForceGC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 872] JS_GC [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1524] nsJSContext::GC [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1287] MSVCRT.DLL + 0xb29e (0x7800b29e) DocumentViewerImpl::Init [d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 532] nsDocShell::SetupNewViewer [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2755] nsWebShell::SetupNewViewer [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 385] nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2341] nsWebShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 409] nsDocShell::CreateContentViewer [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2521] nsDSURIContentListener::DoContent [d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 107] nsDocumentOpenInfo::DispatchContent [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362] nsDocumentOpenInfo::OnStartRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234] nsHTTPFinalListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1118] InterceptStreamListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1178] nsHTTPServerListener::FinishedResponseHeaders [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1056] nsHTTPServerListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 428] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 406] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 576] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 512] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1046] KERNEL32.DLL + 0x242e7 (0xbff942e7) 0x00688b3e
Keywords: topcrash
Summary: crash when smart downloading a zip file; any file on winNT → crash when smart downloading a zip file; any file on winNT [@ js_MarkGCThing]
i found a sneaky case where i couldn't repro this: somehow, at least using comm bits 2000.09.20.05 on winnt, it doesn't crash (mostly*) when i select the Macintosh link (same page i described originally). i can download the mac installer blob (not that that helps on winnt ;), assuming i don't interrupt by surfing (bug 51018). (*) well, i didn't get one crash trying to do this. the trace is pretty similar to the other ones (talkback incident #17747315).
Wow, I see this all the time on Linux now. We need to get the right owner for this. It isn't gagan. navigator.js implements an interface: nsIWebProgressListener. C++ code in nsBrowserInstance forwards progress notifications to the JS object. For some reason, occassionally when we make a onProgress or OnState call to our JS object, we crash down in the bowels of JS calling js_MarkGCThing. cc'ing brendan and jband in the hopes that they can point us in the right direction. Setting priority to P1. I can't download applications on linux without crashing because of this. cc'ing Brendan
Priority: P3 → P1
First, check whether this is a dup of bug 53094: is the memory pointed at by the JSContext *cx passed to JS_GC recently freed? On Windows (at least some flavors) it'll contain 0xdddddddd. If the cx looks like freed memory, you've got a dup. wouldn't expect js_GC to get so far in that case. But maybe Linux doesn't pattern fill free mem. If this is not a dup of 53094, look at thing (the address in that parameter) in the top js_MarkGCThing frame. Go up one frame, and see where thing came from in the calling js_MarkGCThing (your line numbers don't match top of trunk, so I'm not sure). If you can, dump out (in hex) the base and avail members of every JSArena on the linked list starting at cx->runtime->gcArenaPool.first.next and following next links. Jband or I can help debug if you get this in a debugger. I'm at home today, feel free to call me. /be
I'll help find this, but if anyone reproduces it in a debugger before I do, please don't hesitate to call me (my number's in the netscape.com phonebook; ask on #mozilla if you're outside the firewall). /be
Assignee: gagan → brendan
Per Brendan, tracking crash [@ gc_find_flags] in this bug. In today's talkback data, a new stack signature showed up in the topcrash list: gc_find_flags. The stack trace(s) for most of those crashes look like this at the top: gc_find_flags [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 215] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 721] gc_root_marker [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 850] JS_HashTableEnumerateEntries [d:\builds\seamonkey\mozilla\js\src\jshash.c, line 365] js_GC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 1060] or like this: gc_find_flags [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 215] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 721] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_MarkGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 750] js_Mark [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 3068] Here are a few talkback entries: gc_find_flags db33fa58 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 210 Build: 2000091508 CrashDate: 2000-09-15 UptimeMinutes: 1 Total: 1 OS: Windows NT 4.0 build 1381 URL: Comment: opened mail message composition window Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17491345 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17491345 gc_find_flags bdbc4678 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 210 Build: 2000091508 CrashDate: 2000-09-16 UptimeMinutes: 29 Total: 30 OS: Windows 98 4.10 build 67766222 URL: Comment: After cannot send mail from seamonkey webmail Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17512107 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17512107 gc_find_flags 78d675d0 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 210 Build: 2000091508 CrashDate: 2000-09-17 UptimeMinutes: 3 Total: 475 OS: Windows 98 4.10 build 67766222 URL: Comment: loading a page w/ DOM/DHTML demos ... don't know address Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17542981 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17542981 gc_find_flags ecb45be2 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 4 Total: 4 OS: Windows 98 4.10 build 67766446 URL: http://zend.com Comment: Went from slashdot.com to zend.com Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17643264 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17643264 gc_find_flags 69cec914 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000091821 CrashDate: 2000-09-19 UptimeMinutes: 1 Total: 1 OS: Windows 98 4.10 build 67766222 URL: law.mcom.com/download.html Comment: Clicked on http link to medium.zip. Downloading dialog appeared. After a few moments Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17677949 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17677949 gc_find_flags 4e3f7124 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000091909 CrashDate: 2000-09-19 UptimeMinutes: 81 Total: 81 OS: Windows NT 4.0 build 1381 URL: bug 53123 Comment: bug 53123 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17681923 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17681923 gc_find_flags d7413f21 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000092006 CrashDate: 2000-09-20 UptimeMinutes: 36 Total: 36 OS: Windows NT 4.0 build 1381 URL: Comment: Logging into my AOL mail account Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17728101 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17728101 gc_find_flags 69cec914 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 6 Total: 6 OS: Windows 98 4.10 build 67766222 URL: http://law.mcom.com/download.html Comment: Click on the http link to the 32M "really big file." I get the Downloading dialog Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17748039 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17748039 gc_find_flags 9e3a372d http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 0 Total: 187 OS: Windows NT 4.0 build 1381 URL: Comment: downloading 7 M file via http (choice 1 from law's test page) Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17748326 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17748326 gc_find_flags 91dbba15 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000092009 CrashDate: 2000-09-20 UptimeMinutes: 10 Total: 10 OS: Windows NT 4.0 build 1381 URL: http://www.greatowl.com/Editor/Download.htm Comment: attempting to save a file (ice410.exe) to disk. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=17748912 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=17748912 I didn't include the stack trace, since you can access it by clicking on the bottom 2 links of each entry.
Did y'all notice that this is an http url to a really big file? I'm seeing this thing come out of the cache on the second run. It crashes in the netscape build, but not on the mozilla debug build for me. It seems to be downloading the file (and/or pulling it from cache) *before* the native file picker dialog will respond to user input (though it is showing). There is some strange stuff happening here.
I can crash on a mozilla build as well as commercial. Note that many of the talk back reports involve various operations like sending mail, entering a mail password into the password dialog, etc. Seems like the action of downloading the file isn't the only cause. Other areas were windows are getting dismissed trigger this as well.
Attached file interesting stack —
Look at the stack above I got on a purify build. Note that the JSObject* param == 1. And "nsDNSEventProc". This is not the "nsDNSService::Run" thread. Is this event proc supposed to receive this? The cx looks to have the right stuf in it.
jband, your stack trace is dramatically different than the one I see. Looks like you are crashing just bringing up the helper app dialog. I can bring that up, but crash later on after dismissing a file picker dialog.
I like the theory that this crash happens following window dismissal. This correlates well with my experience with the last few days of builds. The best way to have a whole lot of windows to dismiss is to delete all of your cookie and image permissions, then turn on prompting for both cookies and images. Window creation/destruction galore.
That's definetly the scenario I get with this stack trace. We are procesisng a DOM event for closing the window on the stack when we crash in gc_find_flags where we assign into flagp: flagp = pi->flags + ((jsuword) thing & GC_PAGE_MASK) / sizeof(JSGCThing);
Brendan, I noticed that jsgc underwent a large change on 9/13 (version 3.6). The 9/15 builds is when we first started getting talk back reports with the crash in js_MarkGCThing. could the changes from 9/13 caused this problem?
the variable pi seems to be pointing to a bogus address.... attempting to dereference pi->flags. Here's some stuff from gdb that seems to indicate that the address for pi is invalid.... p pi $1 = (JSGCPageInfo *) 0xa1800 p *pi Cannot access memory at address 0xa1800
Mscott: the JS GC did indeed get a big fix the other week, but that fix has no obvious bug. It is, however, vulnerable to latent bugs where bad JS GC-thing pointers are passed into it (via roots) or otherwise occur in the live-object graph that the mark phase traverses. The old GC would effectively bounds-check all nominal GC-thing pointers (tagged or not), which was O(n**2) growth rate and "conservative" (not good for GC running time; not good for an exact GC). Now that I'm able to reproduce this (thanks for your help), I just need to fence the wolf in. /be
Status: NEW → ASSIGNED
Target Milestone: --- → M18
ahh cool, I'm glad you can reproduce it now. I'll be around tonight if you want me to try anything out.
I found the proximate cause of the crash: nsUnknownContentTypeHandler.cpp was calling JS_PushArguments to push 4 args on the JS stack, but then it passed 6, not 4, as the actual argument count to parent->OpenDialog. That leads directly to the construction of the window.arguments array from not 1 but 3 jsvals, the latter 2 uninitialized. I checked all other JS_PushArguments calls I could find under xpfe and dom, and found no more such errors. In reviewing JS_PushArguments, I found a bug in the big GC O(1) instead of O(bad) fix of the other week: in the case where JS_PushArgumentsVA has over-estimated how much stack it will need it was returning the surplus, but failing to reduce the top JSStackHeader.nslots (needed for exact GC, to find those stack slots actually allocated). The patch fixes this bug. We should all apply it and try to reproduce this bug, bug 53094, and any others that smell similar. I suspect strongly that this patch will not fix 53094, but I would love to be proven wrong. Anyone gimme an r=? Jband, you should a=. I'll post to reviewers. /be
Keywords: patch, review
Cc'ing law. Bill, it used to be that the JS GC would tolerate errors such as pushing 4 arguments and then telling OpenDialog you were passing 6, but the cost was too great (see bug 49816, now closed). I think the skidmarks for this sort of bug are branded in our memories (they are in mine). I diagnosed this by looking at the GC-thing being marked, noticing that it was a free memory fill pattern (0xdadadada, used by jsarena.h), and going up one frame to the calling js_MarkGCThing. There, I found that vp - obj->slots was 5, and that the object had 8 slots allocated, 7 valid. Slots 5 and 6 (next-to-last and last) were 0xdadadada, uninitialized. The obj was an array (p *(JSClass *) (obj->slots[2]-1)) and its length (slot 3) was 3 (the jsval is 7, (3<<1)|1 to tag it as a jsint). Slot 4 was the first array element, an XPConnect object. I then went up one more frame and found that the slot being marked was slot 252 in the window object (class check as above, plus going up one more frame got me to gc_root_marker and the root name, (char*)he->value, was "window_object"). obj->freeslot was 267 or some such, so I reckoned I could find the property mapping slot 252 by going backward in the object's scope's property list. This took some real gdb magic: p *(JSScope*)obj->map; p *(JSScopeProperty*) ((char*) $.proptail - 28); p *(JSScopeProperty*) ((char*)$.prevp - 28); and then I hit enter for redo-last-command until I saw a JSScopeProperty with slot == 252. At that point, p *(JSString*)($.id-4) showed a JSString (tag==4, JSString pointers are alinged 0 mod 8, so subtract the tag from the id jsval to get the pointer) with length 9, and x/18c $.chars dumped the UCS2 chars as ASCII, which if you ignore the interleaved '\0' chars spells 'arguments'. Hope this helps people other than me debug such mysterious JS stuff. /be /be
a=jband Awesome Brendan. I was staring at that JS_PushArguments stuff earlier tonight while looking at the one place where I saw this problem. I was wondering about the 6, but I got distracted. See the comments I'll add in bug 53094
I recall adding two extra arguments at some point (content type and content-disposition response header text) and I didn't bump that argument count. Compiled OK, ran OK (up till recently), so never suspected anything. Thanks for the JS debugging tutorial. More than I want to know, actually :-).
law: TMI? Actually it was more than I wanted to know, too ;-) But I put it here in case someone else needs my hobby. jband: thanks, I'll get this in today (hoping the tree opens). Anyone who wants to try the patch, feel free, so we get more testing and see what else it fixes. Soak time is good. /be
Too much for me, right at the moment. I did see the same (or real similar) stack trace last night. I was getting a crash when calling nsICommonDialogs::UniversalDialog during the navigator.xul onload handler. I figured it was just living too close to the edge (I "fixed" it by launching the code via window.setTimeout instead). But now I think I'll go have a look at that function and see if it isn't screwing up the number of arguments. That scenario doesn't seem to resemble bug 50394. Are there other similar things I could look at? BTW, I think maybe bug 53442 is a dup of this bug. But, it doesn't go through the ucth code you fixed. But looking at http://lxr.mozilla.org/seamonkey/source/xpfe/components/ucth/src/nsUnknownContentTypeHandler.cpp#215 I think the 6 should be a 5 in this case. Would overstating the number of arguments produce the same sort of crash? That line should be fixed, regardless. mscott is fixing to make changes to that file; coincidentally, he added another OpenDialog call and copied that broken code, which I caught when reviewing it last night. Scott, can you fix this line, while you're in there?
Bill, The core problem was internal to JS_PushArguments. The numbers or args passed for argc in the actualOpenDialog call is secondary. In this case we have three strings and an interface pointer - 4 args and the numer 4 is right. The thing is that to convert the interface pointer we need to call JS_PushArguments with 2 params to describe the interace - the iid and the pointer. The converter does the right stuff (now). Before it was messing up in managing the stack frame args stuff. This would have been a problem for any call that used a format string whose chars were not one-to-one with arguments. I don't see that any more changes are required.
OK, let's see if I'm less confused now. The argument on the call to OpenDialog is the number arguments that the JS code sees, which may be less than the number passed on the call to JS_PushArguments. Correct? So the 6 should be 4 on the second call to OpenDialog (in nsUnknownContentTypeHandler.cpp). And that's the change Brendan already identified. OK, that's good. Now I don't understand "This would have been a problem for any call that used a format string whose chars were not one-to-one with arguments." What does "one-to-one with arguments" mean? That there was an "s" but the argument was an nsIID*, for example? Might that be happening with the scenario I ran into more recently (using nsICommonDialogs::UniversalDialog from an onload handler)?
law: the number of args pushed must be greater than or equal to the number passed to OpenDialog, and if it's greater than, there's a lesser bug (why push what isn't passed)? jband was talking about the number of *characters* in the format string: "sss%ip" has 6 chars, but specifies 4 args. So 4 are pushed, and the count passed to OpenDialog should be 4 too. /be
[brendan beat me to the site of the mid-air collision, but I'll post anyway...] JS_PushArguments allows for 'plugin' argument formatters. xpconnect supplies one of those. The js engine does not know ahead of time what format string each formatter will use. So, it makes stack space big enough to hold a jsval for each (non-space and non-'*') char in the format string. It then cleans up any extra space after the formatting is done. In this call to JS_PushArguments the format string is "sss%ip", This means 3 strings and an interface pointer. It happens to be 6 chars long. We pass 5 args: 3 strings and an iid and a pointer. the plugin converter in xpconnect handles the "%ip" part. It expects an iid and a pointer and produces one jsval. In this case JS_PushArguments makes space for 6 args and eventually discovers that it only needed space for 4. It cleans up the space it made for the extra 2 args on the JS arg stack. Without the patch it was screwing up in that cleanup and causing later gc problems. When it comes time to actually call openDialog there are really only 4 jsval args in argv. So, passing 4 to openDialog is correct. Because this error was internal to JS_PushArguments we were left in a bad state regardless of what number was passed to openDialog. Does that clear it up?
Yes, thank you. And it explains why I might be seeing a crash when using nsICommonDialogs::UniversalDialog. It calls JS_PushArguments with a "%ip" which means it would screw things up and potentially cause these JS errors. I should see that problem go away, hopefully, when this fix lands? Bad things might happen if you passed "%ip" on JS_PushArguments. Is that a reasonable summary?
Yes, %ip could cause problems since I fixed bug 49816, but I've never seen a stack I could pin on this bug in JS_PushArgumentsVA. Does anyone have a crash in the GC where the stack segments are being marked? http://lxr.mozilla.org/mozilla/source/js/src/jsgc.c#1132 should be on the stack just one or two frames down. /be
brendan, I haven't seen this exactly. But this gc marking is a potential memory corrupter, no? We've seen lots of stuff lately where writing random data on the stack could have been the bad guy. My debug and Purify builds are running a lot happier since I applied the patch. Am I misunderstanding?
jband: a crash seems much likelier, but there could be corruption (mark bits being set in random "flags" bytes -- remember the prefs JSRuntime nightmare of last year, 0x4 appearing randomly?). I just haven't seen anything suggestive. I need to check in, and I was waiting for the tree to open and the branch too. /be
Fixes checked in to branch and trunk. /be
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 53438 has been marked as a duplicate of this bug. ***
wow...nice job guys. I just got back into town and saw that brendan tracked this down. Sweet.
OS: Mac System 9.0 → All
I see a similar trace of jpatel@netscape.com from 21.09.2000 in bug 53094, he pointed me to this bug. at http://www.mindspring.com/~bobclary/tc.html 1. Select All 2. Submit stack- trace: gc_find_flags(void * 0xdadadad8) line 214 + 15 bytes js_MarkGCThing(JSContext * 0x03f4ab30, void * 0xdadadad8, void * 0x00000000) line 720 + 9 bytes js_GC(JSContext * 0x03f4ab30, unsigned int 0x00000001) line 1094 + 87 bytes js_AllocGCThing(JSContext * 0x03f4ab30, unsigned int 0x00000000) line 430 + 11 bytes js_NewObject(JSContext * 0x03f4ab30, JSClass * 0x0055dcd0 _js_ArgumentsClass, JSObject * 0x00000000, JSObject * 0x00000000) line 1440 + 11 bytes js_GetArgsObject(JSContext * 0x03f4ab30, JSStackFrame * 0x007ad278) line 90 + 18 bytes call_getProperty(JSContext * 0x03f4ab30, JSObject * 0x05251938, long 0xffffffff, long * 0x007ad1f0) line 382 + 13 bytes js_GetProperty(JSContext * 0x03f4ab30, JSObject * 0x05251938, long 0x01d4ef80, long * 0x007ad1f0) line 2103 + 125 bytes js_PutCallObject(JSContext * 0x03f4ab30, JSStackFrame * 0x007ad278) line 326 + 21 bytes js_Invoke(JSContext * 0x03f4ab30, unsigned int 0x00000002, unsigned int 0x00000000) line 850 + 16 bytes js_Interpret(JSContext * 0x03f4ab30, long * 0x007addcc) line 2621 + 15 bytes js_Invoke(JSContext * 0x03f4ab30, unsigned int 0x00000005, unsigned int 0x00000001) line 837 + 13 bytes js_Interpret(JSContext * 0x03f4ab30, long * 0x007ae9c0) line 2284 + 15 bytes js_Execute(JSContext * 0x03f4ab30, JSObject * 0x00aa2c98, JSScript * 0x0413f2e0, JSFunction * 0x00000000, JSStackFrame * 0x00000000, unsigned int 0x00000000, long * 0x007ae9c0) line 992 + 13 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x03f4ab30, JSObject * 0x00aa2c98, JSPrincipals * 0x03f17840, const unsigned short * 0x0524695c, unsigned int 0x00000825, const char * 0x0413d350, unsigned int 0x0000000f, long * 0x007ae9c0) line 3146 + 27 bytes nsJSContext::EvaluateString(nsJSContext * const 0x03f4ace0, const basic_nsAReadableString<unsigned short> & {...}, void * 0x00aa2c98, nsIPrincipal * 0x03f1783c, const char * 0x0413d350, unsigned int 0x0000000f, const char * 0x005525f8, basic_nsAWritableString<unsigned short> & {...}, int * 0x007aea1c) line 583 + 68 bytes HTMLContentSink::EvaluateScript(nsString & {...}, nsIURI * 0x03a9d4f0, int 0x0000000f, const char * 0x005525f8) line 4610 HTMLContentSink::ProcessSCRIPTTag(const nsIParserNode & {...}) line 4959 HTMLContentSink::AddLeaf(HTMLContentSink * const 0x03f05dc0, const nsIParserNode & {...}) line 3133 + 12 bytes CNavDTD::AddLeaf(const nsIParserNode * 0x03b8f040) line 3621 + 22 bytes CNavDTD::AddHeadLeaf(nsIParserNode * 0x03b8f040) line 3744 + 17 bytes CNavDTD::HandleStartToken(CToken * 0x0522fc78) line 1567 + 12 bytes CNavDTD::HandleToken(CNavDTD * const 0x03f10550, CToken * 0x00000000, nsIParser * 0x03f068e0) line 745 + 12 bytes CNavDTD::BuildModel(CNavDTD * const 0x03f10550, nsIParser * 0x03f068e0, nsITokenizer * 0x03f119c0, nsITokenObserver * 0x00000000, nsIContentSink * 0x03f05dc0) line 485 + 20 bytes nsParser::BuildModel() line 2010 + 34 bytes nsParser::ResumeParse(int 0x00000001, int 0x00000000) line 1891 + 11 bytes nsParser::EnableParser(int 0x00000001) line 1528 + 15 bytes HTMLContentSink::ResumeParsing() line 4543 + 19 bytes HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x03f05dc4, nsIStreamLoader * 0x040d9190, nsISupports * 0x00000000, unsigned int 0x00000000, unsigned int 0x00010aec, const char * 0x05259684) line 4740 + 11 bytes nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x040d9194, nsIChannel * 0x040ddba0, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 121 + 78 bytes nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x040dd960, nsIChannel * 0x040ddba0, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1158 + 42 bytes InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 0x04098950, nsIChannel * 0x040ddba0, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1199 nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x04098950, unsigned int 0x00000000, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 1877 + 42 bytes nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x0409d040, nsIChannel * 0x040dcc54, nsISupports * 0x040ddba0, unsigned int 0x00000000, const unsigned short * 0x100a56c8 gCommonEmptyBuffer) line 729 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x040df620) line 302 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x040df0a0) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x040df0a0) line 575 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00b8b470) line 508 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00000744, unsigned int 0x0000d827, unsigned int 0x00000000, long 0x00b8b470) line 1044 + 9 bytes KERNEL32! bff7363b() KERNEL32! bff94407() 007a8a32()
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
http://www.mindspring.com/~bobclary/tc.html gives a 404 error. Did you get the url wrong? Or did the site change recently?
BTW, in mozilla http://www.mindspring.com/~bobclary/ seems to go into an infinite loop and freeze. mozilla is so busy spewing warnings that nothing happens... JavaScript strict warning: http://www.mindspring.com/~bobclary/js/bcUtils.js line 109: reference to undefin ed property elm.style.marginLeftWidth JavaScript strict warning: http://www.mindspring.com/~bobclary/js/bcUtils.js line 114: reference to undefin ed property elm.style.marginTopWidth JavaScript strict warning: http://www.mindspring.com/~bobclary/js/bcUtils.js line 109: reference to undefin ed property elm.style.marginLeftWidth JavaScript strict warning: http://www.mindspring.com/~bobclary/js/bcUtils.js line 114: reference to undefin ed property elm.style.marginTopWidth
I selected first one of the testcases at http://www.mindspring.com/~bobclary/domtest/tc.html and saw also the tons of warnigns but they are finite. Then I selected all and saw a lots of warnings and crashed.
I see crashes with the tests at http://www.mindspring.com/~bobclary/domtest/tc.html too. The first time I saw a crash with a stack as shown. We were doing: GC_MARK_JSVALS(cx, nslots, fp->spbase, "operand"); acx->fp == fp. Down deeper the gcthing that we are trying to mark is garbage. The second time I'm seeing a crash in the C runtime's realloc while trying to js_AllocSlot. I'll attach a stack.
Attached file realloc crash stack —
I'm seeing the crash in test 23 there. But running test 23 by itself does not crash. select all and submit reproduces the bug pretty reliably. I'm running the new branch on NT. Also, I should not have said that 'thing' was garbage. As can be seen in the stack, it is: 0xdadadad8. This is, of course, the free'd memory pattern with bit 1 cleared.
1 == nslots = fp->sp - fp->spbase; But both those pointers point at memory with value 0xdadadada. Is the engine confused? or do we have some native code that is calling free on memory in the JS stack? Actually, I see that these pointers point into near the begining of a very large block of memory marked with '0xda'. Are we maybe reallocing out from under these guys?
Or maybe we just haven't bothered to init this memory and didn't plan on the possibility that js_AllocGCThing would do the "last ditch" call to js_GC? I dunno.
Brendan, sorry I missed your phone call. I don't have further insight. I have this test suite running under Purify on my machine in MtView (been running for a long time). It hit bug 54242 and I continued it. I haven't dug further into the code. I can reproduce the bug pretty consistently on NT (though sometimes it completes without error and running once or twice again is required to trip it). Hopefully you can do the same. Let me know how I can help.
Got a two-line patch, need to get it into branch and trunk. /be
Status: REOPENED → ASSIGNED
Keywords: rtm
Attached patch proposed fix — — Splinter Review
This bug really shouldn't have been reopened, but oh well. The reopening crash is due to a GC safety bug latent in the old "semi-conservative" GC, and when I fixed the GC to be exact (bug 49816, no O(bad) gc_find_flags), the latent bug started biting. The problem lies in stack pointer not being homed at the bottom of js_Interpret, just before we free raw stack that the GC might scan if fp->sp is != fp->spbase. If the calling js_Invoke then has to put a call object (js_PutCallObject, and in so doing has to run the GC as a last-ditch attempt when nominally out of memory (up against the runtime's GC thing limit), the last-ditch GC will scan freed stack slots (just one slot, I claim). Now it is weird that during js_PutCallObject, we are calling js_GetArgsObject. That's another bug that could be optimized: if you have a call object but no args object (you're a stack frame ;-) then why bother making the latter when releasing the former? I'll file that for later. Looking for r/a= love, and beard help with the PDT. /be
Adding mccabe for hoped-for r=. /be
Adding trudelle, for nsbeta3 and rtm nomination love. This one is a topcrash, although I think the reopened bug (not the original) may be less likely -- you have to allocate a bunch of JS GC things. But a one-line (sans comment) fix that takes this bug out of the background noise for PR3 sounds good to me. /be
a=jband. This makes the test case not crash. I understand that fp != null is an invarient here, but somehow I'd feel better if this line were preceeded with an assert... JS_ASSERT(fp);
r=mccabe. Backstops every problem path I can see.
Adding nsbeta3+/rtm+ to get on PDT radar. To get into nsbeta3, someone will need to plead this to PDT, and unless there is still a common crash case, I doubt it will make the cut.
Whiteboard: [nsbeta3+][rtm+] ONE LINE FIX READY TO LAND
jband: truly, it would be vacuous to assert that fp is non-null. The structure of js_Interpret, gigantic thought that function may be, is: init; while (pc < endpc) { switch (*pc) { ... } pc += len; } out: if (!ok) { ... } cleanup; fp is set in init and used in cleanup and throughout the switch cases. We'd do better to assert that it wasn't a pointer into freed memory, but that's not so easy to assert. I'm not going to assert that it's non-null (the save-restore code in inline_call: and inline_return: is balanced by the compiler). But here is my real reason: Assertions that a pointer is non-null right before dereferencing that pointer are vacuous because the deref will crash just as good as the assert will, and give even more direct, immediate information to debugger-drivers. And asserts and crashes with symbols are for debugger-driving hackers to study, not for end users. So unless there were an 'if (!fp) {defensive code here}' after such an assertion, there's no point in just asserting and dereferencing. /be
Sorry brendan, I could have saved you the typing - I had the same thought right after hitting the commit button.
nsbeta3++
Whiteboard: [nsbeta3+][rtm+] ONE LINE FIX READY TO LAND → [nsbeta3++][rtm+] ONE LINE FIX READY TO LAND
Fixed in trunk and in Netscape_20000922_BRANCH. /be
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
*** Bug 53438 has been marked as a duplicate of this bug. ***
*** Bug 54227 has been marked as a duplicate of this bug. ***
verified in branch: WinNT 2000100908 Mac os9 2000100910 need to verify in trunk
Keywords: vtrunk
This crash appears to have returned in some form. Here are the latest entries: js_MarkGCThing a9e586ce http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 750 Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 1 Total: 1 OS: Windows 98 4.10 build 67766446 URL: Comment: crash related to bug 54896 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19188106 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19188106 js_MarkGCThing() f6e56175 jsgc.c line 721 Build: 2000101608 CrashDate: 2000-10-16 UptimeMinutes: 2 Total: 2 OS: MacOS version 9.0 URL: Comment: crash related to bug 54896 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19188618 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19188618 js_MarkGCThing() d8ee2b8a line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 15 Total: 15 OS: Linux 2.2.12-20smp URL: Comment: crash related to bug 54896 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19188997 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19188997 js_MarkGCThing() 647a2857 line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 122 Total: 122 OS: Linux 2.2.16-22enterprise URL: Comment: Went to theme selection Pull down menu (View -> Apply Theme) Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19193799 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19193799 js_MarkGCThing() 7525c375 line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 4 Total: 5 OS: Linux 2.2.17 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19200512 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19200512 js_MarkGCThing() 9abb6ddc line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 0 Total: 0 OS: Linux 2.2.17 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19201403 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19201403 js_MarkGCThing 7bd6c165 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 721 Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 55 Total: 55 OS: Windows 98 4.90 build 73010104 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19206388 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19206388 js_MarkGCThing() fb777dd6 line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 17 Total: 17 OS: Linux 2.4.0-test9 URL: PSM install for Linux Comment: Crash happened right after clicking the "Install Linux PSM" button Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19212280 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19212280 js_MarkGCThing() 359d5b80 line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 40 Total: 58 OS: Linux 2.4.0-test9 URL: Java 2.0 plugin install for Linux Comment: Clicked "cancel" button Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19214235 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19214235 js_MarkGCThing() 3d0b4447 line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 134 Total: 134 OS: Linux 2.2.16-22 URL: Comment: quitting mozilla Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19216919 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19216919 Another bug mentioned in the user comments is bug 54896. Reopening in case this latest crash is indeed related to the one fixed recently.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
My previous comments were for js_MarkGCThing crashes. Here are some entries for the latest gc_find_flags crashes also: gc_find_flags 5c2ba49b http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 51 Total: 51 OS: Windows NT 4.0 build 1381 URL: www.abcnews.go.com Comment: Just typing in the url and hitting enter crashed Seamonkey. Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19193042 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19193042 gc_find_flags() feda89fc line Build: 2000101609 CrashDate: 2000-10-16 UptimeMinutes: 1 Total: 1 OS: Linux 2.2.16 URL: Comment: trying to install java 2 plugin Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19197087 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19197087 gc_find_flags cd123fd1 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000101309 CrashDate: 2000-10-13 UptimeMinutes: 3 Total: 3 OS: Windows NT 4.0 build 1381 URL: Comment: reading mail Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19029070 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19029070 gc_find_flags 16ab37bb http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000101309 CrashDate: 2000-10-13 UptimeMinutes: 184 Total: 184 OS: Windows NT 4.0 build 1381 URL: Comment: crash trying to send a message Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19039496 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19039496 gc_find_flags() b7c465b4 jsgc.c line 213 Build: 2000101308 CrashDate: 2000-10-13 UptimeMinutes: 11 Total: 11 OS: MacOS version 8.6 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19041783 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19041783 gc_find_flags 5edf0504 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsgc.c line 215 Build: 2000101213 CrashDate: 2000-10-16 UptimeMinutes: 2926 Total: 2926 OS: Windows NT 4.0 build 1381 URL: Comment: Instant Messenger and Browser crash Detailed : http://climate/reports/incidenttemplate.cfm?bbid=19154390 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=19154390
Summary: crash when smart downloading a zip file; any file on winNT [@ js_MarkGCThing] → crash when smart downloading a zip file; any file on winNT [@ js_MarkGCThing][@ gc_find_flags]
I'd really rather see us open a new bug to track new crashes with similar stacks. This bug was already overloaded with (at least) two separate sets of bugs and fixes. Please, let's not confuse it (and us!) with a third.
Ok, sorry...i'm making this resolved fixed again and will log 2 separate bugs for the js_MarkGCThing crash and gc_find_flags crash.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
jpatel: please also include full stack backtraces. Blaming the topmost function is next-to-useless, as I have tried to point out in urging you several times to look two frames down for gc_root_marker. /be
Ok, well neither of the new stack traces have gc_root_marker in them anywhere...so I just logged two new bugs: bug 57066 - top function is js_MarkGCThing bug 57070 - top function is gc_find_flags, followed immediately by js_MarkGCThing
verified on branch: winNT 2000101908 Linux rh6 2000101909 Mac os9 2000101908
verified on trunk 11/01 RH7 Linux 10/23 MacOS9 11/01 WinNT 4.0 Marking this verified and removing vtrunk keyword
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Reopening this bug: This is a topcrash for M09. Added crash M09 [@ gc_find_flags] for tracking. Here are some URLs and Comments to help in reproducing this crash: (30146222) URL: theme.org (30146222) Comments: installing theme called "thinnice". The error is reproducable. (30145432) URL: x.themes.org (30145432) Comments: Installing the early blue skin. (30142139) Comments: Loading new theme (30132355) Comments: INstalling JRE (30131409) Comments: Installing a theme that ended with an "Unspecified Error Code" (30130990) Comments: Trying to install Lopburi Flat Theme (30130083) Comments: Installing a theme. Here is a recent stack trace: Incident ID 30146222 gc_find_flags() js_MarkGCThing() js_MarkGCThing() js_MarkGCThing() js_MarkGCThing() js_GC() js_ForceGC() js_DestroyContext() JS_DestroyContext() nsJSContext::~nsJSContext() nsJSContext::Release() nsCOMPtr_base::~nsCOMPtr_base() nsJSContext::CallEventHandler() nsJSEventListener::HandleEvent() nsEventListenerManager::HandleEventSubType() nsEventListenerManager::HandleEvent() nsXULElement::HandleDOMEvent() PresShell::HandleDOMEventWithTarget() nsButtonBoxFrame::MouseClicked() nsButtonBoxFrame::HandleEvent() PresShell::HandleEventInternal() PresShell::HandleEventWithTarget() nsEventStateManager::CheckForAndDispatchClick() nsEventStateManager::PostHandleEvent() PresShell::HandleEventInternal() PresShell::HandleEvent() nsView::HandleEvent() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWidget::DispatchMouseEvent() nsWidget::OnButtonReleaseSignal() nsWindow::HandleGDKEvent() dispatch_superwin_event() handle_gdk_event() libgdk-1.2.so.0 + 0x179e4 (0x4070f9e4) libglib-1.2.so.0 + 0x10be6 (0x40740be6) libglib-1.2.so.0 + 0x11213 (0x40741213) libglib-1.2.so.0 + 0x112da (0x407412da) nsAppShell::DispatchNativeEvent() nsXULWindow::ShowModal() nsWebShellWindow::ShowModal() nsContentTreeOwner::ShowAsModal() nsWindowWatcher::OpenWindowJS() nsWindowWatcher::OpenWindow() nsPromptService::DoDialog() nsPromptService::Alert() XPTC_InvokeByIndex() EventHandler() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xf350 (0x4073f350) libglib-1.2.so.0 + 0x10be6 (0x40740be6) libglib-1.2.so.0 + 0x11213 (0x40741213) libglib-1.2.so.0 + 0x113dc (0x407413dc) libgtk-1.2.so.0 + 0x9204c (0x4065d04c) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x1cbaf (0x401ffbaf)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: crash when smart downloading a zip file; any file on winNT [@ js_MarkGCThing][@ gc_find_flags] → crash when smart downloading a zip file; any file on winNT; crash M09 [@ js_MarkGCThing, @ gc_find_flags]
File a new bug please, per jband's comments dated 2000-10-17 13:24. I'd say to assign it to xpinstall, probably dbragg. It's familiar. I'm closing this again, the bug that was reported and diagnosed was indeed fixed by the "proposed fix" patches attached here. /be
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Ok. New bug created: bug 80746
oops, that was supposed to be: Bug 80857
qa to me. VERIFIED: Thanks to tever and rodney.
QA Contact: tever → benc
verified
Status: RESOLVED → VERIFIED
Crash Signature: [@ js_MarkGCThing, @ gc_find_flags]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: