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

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[sairuh (rarely reading bugmail)]

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

Comment 1

[sairuh (rarely reading bugmail)]

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

Comment 2

[John Morrison]

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).

Comment 3

[Scott MacGregor]

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.

Comment 4

[sairuh (rarely reading bugmail)]

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               [e-mail] 
 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

Comment 5

[sairuh (rarely reading bugmail)]

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.

Comment 6

[Scott MacGregor]

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.

Comment 7

[sairuh (rarely reading bugmail)]

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.

Comment 8

[Jay Patel [:jay]]

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 

Comment 9

[sairuh (rarely reading bugmail)]

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).

Comment 10

[Scott MacGregor]

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

Comment 11

[Brendan Eich [:brendan]]

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

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Jay Patel [:jay]]

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.

Comment 14

[John Bandhauer]

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.

Comment 15

[Scott MacGregor]

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.

Comment 16

[John Bandhauer]

Attachment: interesting stack

Comment 17

[John Bandhauer]

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.

Comment 18

[Scott MacGregor]

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.

Comment 19

[Jeffrey Baker]

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.

Comment 20

[Scott MacGregor]

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);

Comment 21

[Scott MacGregor]

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?

Comment 22

[Scott MacGregor]

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

Comment 23

[Brendan Eich [:brendan]]

Attachment: mscott's mimeTypes.rdf, which helped me reproduce the crash

Comment 24

[Brendan Eich [:brendan]]

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

Comment 25

[Scott MacGregor]

ahh cool, I'm glad you can reproduce it now. I'll be around tonight if you want
me to try anything out.

Comment 26

[Brendan Eich [:brendan]]

Attachment: proposed fix to nsUnknownContentTypeHandler.cpp, plus bonus fix in JS_PushArguments*

Comment 27

[Brendan Eich [:brendan]]

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

Comment 28

[Brendan Eich [:brendan]]

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

Comment 29

[John Bandhauer]

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

Comment 30

[Bill Law]

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 :-).

Comment 31

[Brendan Eich [:brendan]]

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

Comment 32

[Bill Law]

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?

Comment 33

[John Bandhauer]

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.

Comment 34

[Bill Law]

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)?

Comment 35

[Brendan Eich [:brendan]]

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

Comment 36

[John Bandhauer]

[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?

Comment 37

[Bill Law]

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?

Comment 38

[Brendan Eich [:brendan]]

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

Comment 39

[John Bandhauer]

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?

Comment 40

[Brendan Eich [:brendan]]

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

Comment 41

[Brendan Eich [:brendan]]

Fixes checked in to branch and trunk.

/be

Comment 42

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 53438 has been marked as a duplicate of this bug. ***

Comment 43

[Scott MacGregor]

wow...nice job guys. I just got back into town and saw that brendan tracked this
down. Sweet.

Comment 44

[Bernd Mielke]

I see a similar trace of [e-mail] 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()

Comment 45

[Bob Clary [:bc] (inactive)]

corrected url:

http://www.mindspring.com/~bobclary/domtest/tc.html

Comment 46

[John Bandhauer]

http://www.mindspring.com/~bobclary/tc.html gives a 404 error. Did you get the 
url wrong? Or did the site change recently?

Comment 47

[John Bandhauer]

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

Comment 48

[Bernd Mielke]

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.

Comment 49

[John Bandhauer]

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.

Comment 50

[John Bandhauer]

Attachment: realloc crash stack

Comment 51

[John Bandhauer]

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.

Comment 52

[John Bandhauer]

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?

Comment 53

[John Bandhauer]

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.

Comment 54

[John Bandhauer]

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.

Comment 55

[Brendan Eich [:brendan]]

Got a two-line patch, need to get it into branch and trunk.

/be

Comment 56

[Brendan Eich [:brendan]]

Attachment: proposed fix

Comment 57

[Brendan Eich [:brendan]]

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

Comment 58

[Brendan Eich [:brendan]]

Attachment: final proposed fix (handles unbalanced stack after error)

Comment 59

[Brendan Eich [:brendan]]

Adding mccabe for hoped-for r=.

/be

Comment 60

[Brendan Eich [:brendan]]

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

Comment 61

[John Bandhauer]

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);

Comment 62

[Mike McCabe]

r=mccabe.  Backstops every problem path I can see.

Comment 63

[Peter Trudelle]

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.

Comment 64

[Brendan Eich [:brendan]]

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

Comment 65

[John Bandhauer]

Sorry brendan, I could have saved you the typing - I had the same thought right 
after hitting the commit button.

Comment 66

[Phil Peterson]

nsbeta3++

Comment 67

[Brendan Eich [:brendan]]

Fixed in trunk and in Netscape_20000922_BRANCH.

/be

Comment 68

[John Bandhauer]

*** Bug 53438 has been marked as a duplicate of this bug. ***

Comment 69

[Brendan Eich [:brendan]]

*** Bug 54227 has been marked as a duplicate of this bug. ***

Comment 70

[Tom Everingham]

verified in branch:
WinNT 2000100908
Mac os9 2000100910

need to verify in trunk

Comment 71

[Jay Patel [:jay]]

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.

Comment 72

[Jay Patel [:jay]]

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

Comment 73

[John Bandhauer]

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.

Comment 74

[Jay Patel [:jay]]

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.

Comment 75

[Brendan Eich [:brendan]]

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

Comment 76

[Jay Patel [:jay]]

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

Comment 77

[Tom Everingham]

verified on branch:

winNT 2000101908
Linux rh6 2000101909
Mac os9 2000101908

Comment 78

[Rodney Velasco]

verified on trunk
11/01 RH7 Linux
10/23 MacOS9
11/01 WinNT 4.0
Marking this verified and removing vtrunk keyword

Comment 79

[Jan Carpenter]

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) 

Comment 80

[Brendan Eich [:brendan]]

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

Comment 81

[Jan Carpenter]

Ok.  New bug created: bug 80746

Comment 82

[Jan Carpenter]

oops, that was supposed to be: Bug 80857

Comment 83

[benc]

qa to me.

VERIFIED: 
Thanks to tever and rodney.

Comment 84

[benc]

verified