48934 - Intermittent crash on startup, apparently in garbage collector

Status: RESOLVED DUPLICATE of bug 43466

(SeaMonkey :: General, defect, P3)

Description

[Stephen P. Morse]

I had been seeing this for the past few days but just assumed that it was due to 
some local changes that I had in my tree.  Last night I pulled and built a fresh 
tree and I'm still seeing it.

Running mozilla build on win NT.  I go through the profile manager (because I 
have several profiles) and after clicking the START-MOZILLA button I get the 
following crash in the garbage collector:

NTDLL! 77f76274()
gc_root_marker(JSHashEntry * 0x02875570, int 0, void * 0x00cc1d80) line 789 + 35 
bytes
JS_HashTableEnumerateEntries(JSHashTable * 0x00b39820, int (JSHashEntry *, int, 
void *)* 0x002b1063 gc_root_marker(JSHashEntry *, int, void *), void * 
0x00cc1d80) line 364 + 15 bytes
js_GC(JSContext * 0x025202d0, unsigned int 0) line 957 + 21 bytes
js_ForceGC(JSContext * 0x025202d0) line 814 + 11 bytes
JS_GC(JSContext * 0x025202d0) line 1166 + 9 bytes
nsJSContext::GC(nsJSContext * const 0x025205e0) line 1141 + 13 bytes
nsDocShell::SetupNewViewer(nsDocShell * const 0x02526e40, nsIContentViewer * 
0x026f0f30) line 2666
nsWebShell::SetupNewViewer(nsWebShell * const 0x02526e40, nsIContentViewer * 
0x026f0f30) line 386 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x02526e60, nsIContentViewer * 0x026f0f30, 
const char * 0x018fcf14, nsISupports * 0x00000000) line 2380 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x02526e60, nsIContentViewer * 0x026f0f30, 
const char * 0x018fcf14, nsISupports * 0x00000000) line 419
nsDocShell::CreateContentViewer(nsDocShell * const 0x02526e40, const char * 
0x0012fac0, nsIChannel * 0x02520b30, nsIStreamListener * * 0x0012fb14) line 2548 
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x02525220, 
const char * 0x0012fac0, int 0, const char * 0x100a1088 gCommonEmptyBuffer, 
nsIChannel * 0x02520b30, nsIStreamListener * * 0x0012fb14, int * 0x0012faa4) 
line 100 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x02520b30, nsISupports * 
0x00000000) line 359 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x02520ac0, 
nsIChannel * 0x02520b30, nsISupports * 0x00000000) line 233 + 16 bytes
nsStreamIOChannel::OnStartRequest(nsStreamIOChannel * const 0x02520b34, 
nsIChannel * 0x025209b0, nsISupports * 0x00000000) line 599
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x025e91f0) 
line 210 + 26 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x025e85c0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x025e85c0) line 587 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f88d80) line 528 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0076071c, unsigned int 49421, unsigned int 0, 
long 16289152) line 1043 + 9 bytes
USER32! 77e71268()
00f88d80()

Comment 1

[Stephen P. Morse]

Here's the last things that I see on the consule at the time of the crash.

*** going to create a new profile called Default User in folder: Y:\mozilla\dist
\WIN32_D.OBJ\Users50
ProfileManager : CreateNewProfile
Profile Name: Default User
Profile Dir: Y:\mozilla\dist\WIN32_D.OBJ\Users50
WEBSHELL- = 2
WEBSHELL- = 1
start with profile: Default User
ProfileManager : StartApprunner
profileName passed in: Default UserProfileName : Default User
ProfileDir  : Y:\mozilla\dist\WIN32_D.OBJ\Users50\Default User
WEBSHELL- = 0
WEBSHELL+ = 1
Initialized app shell component {33e569b0-40f8-11d4-9a41-000064657374}, rv=0x000
00000
Initialized app shell component {18c2f989-b09f-11d2-bcde-00805f0e1353}, rv=0x000
00000
WEBSHELL+ = 2
CSSLoaderImpl::LoadAgentSheet: Load of URL 'file:///Y|/mozilla/dist/WIN32_D.OBJ/
Users50/Default%20User/chrome/user.css' failed.  Error code: 18

Comment 2

[Stephen P. Morse]

I should point out that the error code 18 in the above console output has 
nothing to do with the crash.  I get the same output for a run that doesn't 
crash.  However the output doesn't end on that line but instead coninues on.  
The next few lines in the output when there is no crash are as follows:

Enabling Quirk StyleSheet
Enabling Quirk StyleSheet
Obtained name of Personal Toolbar from bookmarks string bundle.
Start reading in bookmarks.html
Finished reading in bookmarks.html  (130000 microseconds)
...etc

Comment 3

[leger]

karnaze, any idea who should look at this first?  Putting on [dogfood-] due to 
intermittent.  Will leave nsbeta+ or nsbeta- indication to whomever the eng mgr 
ewnds up to be.

Comment 4

[Marc Attinasi]

Reassigning to Javascript Engine since the crash is int the JS GC. It looks 
unrelated to layout...

Comment 5

[leger]

Adding crash keyword.

Comment 6

[Phil Schwartau]

I was able to reproduce this bug using a Mozilla tip build 2000-08-15 on WinNT. 
Steps to reproduce: 

1. Launch Mozilla in the debug console via  ./mozilla.exe -ProfileManager.

2. Create a NEW profile with the Profile Manager. 
   (I never crashed while choosing an existing profile.)

3. Click on "Start Mozilla"  CRASH!


WINDOWS STACK TRACE
***At the crash point in gc_root_marker, (*char)he->value = "window_object"


NTDLL! 77f7629c()
gc_root_marker(JSHashEntry * 0x029cd8d0, int 26, void * 0x010d1d40) line 789 + 
35 bytes
JS_HashTableEnumerateEntries(JSHashTable * 0x00f45c70, int (JSHashEntry *, int, 
void *)* 0x002a1063 gc_root_marker(JSHashEntry *, int, void *), void * 
0x010d1d40) line 364 + 15 bytes
js_GC(JSContext * 0x023aa430, unsigned int 0) line 957 + 21 bytes
js_ForceGC(JSContext * 0x023aa430) line 814 + 11 bytes
JS_GC(JSContext * 0x023aa430) line 1166 + 9 bytes
JS_MaybeGC(JSContext * 0x023aa430) line 1185 + 9 bytes
nsJSContext::ScriptEvaluated(nsJSContext * const 0x023aa5c0) line 1158 + 13 
bytes
nsJSContext::ExecuteScript(nsJSContext * const 0x023aa5c0, void * 0x011aa268, 
void * 0x010d4fa0, nsString * 0x00000000, int * 0x00000000) line 688
nsXULDocument::ExecuteScript(JSObject * 0x011aa268) line 5628 + 33 bytes
nsXULDocument::OnStreamComplete(nsXULDocument * const 0x023ad1ac, 
nsIStreamLoader * 0x02d78770, nsISupports * 0x00000000, unsigned int 0, unsigned 
int 10033, const char * 0x011b5fc0) line 5576 + 18 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x02d78774, nsIChannel * 
0x02d790e0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a1088 gCommonEmptyBuffer) line 121 + 78 bytes
nsResChannel::EndRequest(unsigned int 0, const unsigned short * 0x100a1088 
gCommonEmptyBuffer) line 708 + 50 bytes
nsResChannel::OnStopRequest(nsResChannel * const 0x02d790e4, nsIChannel * 
0x02d78300, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a1088 gCommonEmptyBuffer) line 702
nsFileChannel::OnStopRequest(nsFileChannel * const 0x02d78308, nsIChannel * 
0x02d79e20, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x100a1088 gCommonEmptyBuffer) line 632 + 45 bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x02d79830) line 
302
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02d799e0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x02d799e0) line 587 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01321370) line 528 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0079030c, unsigned int 49411, unsigned int 0, 
long 20058992) line 1043 + 9 bytes
USER32! 77e71820()
01321370()

Comment 7

[Phil Schwartau]

Intermittent - unable to crash every time on WinNT after creating new profile.
Unable to crash on Linux after creating a new profile.

cc'ing Brendan to get his opinion of where this bug should go.
Note when I did crash, in gc_root_marker, (*char)he->value = "window_object"

Comment 8

[Brendan Eich [:brendan]]

Probably a dup of danm's bug 43466.

/be

Comment 9

[Phil Schwartau]

Assigning to danm for a look; does this seem like a dup of bug 43466?
Doesn't seem like an engine bug; changing component to Browser-General.

Comment 10

[Peter Trudelle]

need info: How frequently does this happen?  In opt builds?  Many talkback 
reports on it?  cc jrgm

Comment 11

[Stephen P. Morse]

I don't have a frequency number to give you, but it's much greater than 0%.  I'm 
using debug builds so I don't know about optimized builds.

Comment 12

[Peter Trudelle]

I can't see plussing it unless it affects the opt builds, since that's what
we're shipping.

Comment 13

[John Morrison]

I could find 17 Talkback incidents that crashed in gc_root_marker on a GC that
resulted from the same stack that morse had. (I can't find a duplicate of 
schwartau's call stack.)

...  nsWebShell::SetupNewViewer
     nsDocShell::Embed
     nsWebShell::Embed ...

I don't know if 17 is a large number or a small number to find. [Curiously 
though, ~14 of the 17 all had the same build ID (2000080712), even though 
the dates of the actual crash range from that time up to the present.]

Comment 14

[Peter Trudelle]

Did any have recent build IDs?  Can we tell if any were opt builds?

Comment 15

[John Morrison]

When I did this check, none had recent build ID's (i.e., they were all 08/07
or earlier, and I did the query 08/17). These are all opt builds, since AFAIK
talkback is only bundled into the release/opt builds.

Comment 16

[Stephen P. Morse]

I just got the crash with a tree that I pulled and built last night.

Comment 17

[Peter Trudelle]

So, it sounds like it was at one time a problem in opt builds, but is now just
an intermittent problem in debug builds.  Daniel, are you able to repro this?
Is it a dup?

Comment 18

[Dan M]

No. Therefore, can't be sure. Seems likely, though.

Comment 19

[Peter Trudelle]

resolving as dup, please don't verify until satisfied that the fix for bug 
43466 fixes this as well.

*** This bug has been marked as a duplicate of 43466 ***