379491 - Crash on every other startup (when reading fastload?)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

My firefox crashes on every other startup.  The first problem it runs into, apparently, is that nsTranscodeJSPrincipals reports an NS_ERROR_FAILURE.

This is not too surprising to me; there's various breakage in principal serialization/deserialization, really.

Be that as it may, we move right along, report the error:

JS Component Loader: ERROR (null):0
                     can't decode principals (failure code 80004005)
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file ../../../../../mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp, line 948
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file ../../../../../mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp, line 948

and then die with:

Assertion failure: nentries != 0, at ../../../mozilla/js/src/jshash.c:227

#0  JS_Assert (s=0xb7bada55 "nentries != 0", 
    file=0xb7bada1c "../../../mozilla/js/src/jshash.c", ln=227)
    at ../../../mozilla/js/src/jsutil.c:63
#1  0xb7b22477 in Resize (ht=0x8109138, newshift=20)
    at ../../../mozilla/js/src/jshash.c:227
#2  0xb7b22565 in JS_HashTableRawAdd (ht=0x8109138, hep=0x81f9120, keyHash=943612147, 
    key=0x820798c, value=0x0) at ../../../mozilla/js/src/jshash.c:257
#3  0xb7af1730 in js_AtomizeString (cx=0x81af640, str=0x8207988, flags=128)
    at ../../../mozilla/js/src/jsatom.c:697
#4  0xb7af18f3 in js_AtomizeChars (cx=0x81af640, chars=0x8200da8, length=15, flags=0)
    at ../../../mozilla/js/src/jsatom.c:763
#5  0xb7b79a8b in js_GetToken (cx=0x81af640, ts=0x81e30b8)
    at ../../../mozilla/js/src/jsscan.c:1354
#6  0xb7b5f323 in FunctionDef (cx=0x81af640, ts=0x81e30b8, tc=0xbfffd19c, lambda=0)
    at ../../../mozilla/js/src/jsparse.c:1221
#7  0xb7b5fa4b in FunctionStmt (cx=0x81af640, ts=0x81e30b8, tc=0xbfffd19c)
    at ../../../mozilla/js/src/jsparse.c:1444
#8  0xb7b62134 in Statement (cx=0x81af640, ts=0x81e30b8, tc=0xbfffd19c)
    at ../../../mozilla/js/src/jsparse.c:2544
#9  0xb7b5fb64 in Statements (cx=0x81af640, ts=0x81e30b8, tc=0xbfffd19c)
    at ../../../mozilla/js/src/jsparse.c:1476
#10 0xb7b5dc8c in js_CompileTokenStream (cx=0x81af640, chain=0x81db8a0, ts=0x81e30b8, 
    cg=0xbfffd19c) at ../../../mozilla/js/src/jsparse.c:501
#11 0xb7ae8be0 in CompileTokenStream (cx=0x81af640, obj=0x81db8a0, ts=0x81e30b8, 
    tempMark=0x81af6a0, eofp=0x0) at ../../../mozilla/js/src/jsapi.c:4288
#12 0xb7ae8e42 in JS_CompileUCScriptForPrincipals (cx=0x81af640, obj=0x81db8a0, 
    principals=0x81b27f4, chars=0xb5634008, length=318886, 
    filename=0x81e3020 "file:///home/bzbarsky/mozilla/vanilla/obj-firefox/dist/bin/components/nsExtensionManager.js", lineno=0) at ../../../mozilla/js/src/jsapi.c:4383
#13 0xb7ae8d7f in JS_CompileScriptForPrincipals (cx=0x81af640, obj=0x81db8a0, 
    principals=0x81b27f4, 
    bytes=0xb56d0000 "/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */\n/* ***** BEGIN LICENSE BLOCK *****\n * Version: MPL 1.1/GPL 2.0/LGPL 2.1\n *\n * The contents of this file are subject to t"..., length=318886, 
    filename=0x81e3020 "file:///home/bzbarsky/mozilla/vanilla/obj-firefox/dist/bin/components/nsExtensionManager.js", lineno=0) at ../../../mozilla/js/src/jsapi.c:4338
#14 0xb74cce24 in mozJSComponentLoader::GlobalForLocation (this=0x8105450, 
    aComponent=0x81e0710, aGlobal=0x81e0654, aLocation=0x81e0658)
    at ../../../../../mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp:1169
#15 0xb74c9990 in mozJSComponentLoader::LoadModule (this=0x8105450, 
    aComponentFile=0x81e0710, aResult=0xbfffd8fc)

This makes it really hard to debug using this build, and pretty much impossible to debug anything involving fastload...

Comment 1

[Boris Zbarsky [:bzbarsky]]

Oh, I checked.  The principal being deserialized is an nsSystemPrincipal, and as far as I can tel we're ending up with a |size| of 1580 in nsTranscodeJSPrincipals, then failing on the ReadBytes.

I don't have any local changes to the JS engine or to system principal serialization in this tree.

I also have no enabled extensions other than DOM Inspector.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So this bug basically makes it impossible to use Firefox for any serious debugging.  I can use Seamonkey for most things, but some bugs on my plate are Firefox-specific-ish, and I can't debug them in a sane way...

Comment 3

[Robert Sayre]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/xpconnect/loader/mozJSComponentLoader.cpp&rev=1.132#941

tells us that we "don't warn since NOT_AVAILABLE is an ok error". GlobalForLocation resets this error code to NS_OK. 

However, it looks like the calls to the fastload service that follow can return that same error. Are those still ok? 

Comment 4

[Boris Zbarsky [:bzbarsky]]

Was that question directed at me?  If so, I'm not sure I follow what you're asking...

Comment 5

[Robert Sayre]

(In reply to comment #4)
> Was that question directed at me?

No.

Comment 6

[Brendan Eich [:brendan]]

Anyone else seeing this? I'm not. Boris, what's your secret? ;-)

/be

Comment 7

[Boris Zbarsky [:bzbarsky]]

I don't know.  In fact, I'm only seeing this with some of my trees, not all of them.  All are running against the same profile.  Unfortuntely, my main development tree is one of the problem trees.

I did check that none of the changes in the relevant tree are to blame (no real changes in JS or caps).

I'm happy to provide more info if people want it, including a treediff or whatnot.  I just don't know what would be useful.

Comment 8

[Brendan Eich [:brendan]]

Sure, post a tree-wide cvs diff of a problem build's tree -- smallest diff output amont all problem trees is best.

/be

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Treediff

I'd also happily provide whatever fastload files people want, etc.

Oh, and did I mention that I only run into this with Firefox, not with Seamonkey?  And there are no non-default extensions in the profile?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Fwiw, it looks like I now only have one tree that shows the problem -- my main tree.  Odd.  The other trees used to have it too...

Comment 11

[Boris Zbarsky [:bzbarsky]]

I hit this again today and did some more digging, with brendan's help.  Bug   	387572 covers the memory corruption that causes the crash, while bug 387588 covers the reason that deserialization fails.  With both fixed, life is good here.  ;)