863646 - Start up crash in nsContentUtils::GetCurrentJSContext in profile manager (-p <empty>, -profilemanager, always ask at startup)

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Alice0775 White]

Attachment: WinDbg Log

Last Good: 0c0d7f9cb43d
First Bad: ba928cbd5191

Comment 1

[Alice0775 White]

The crash happens if specified command line option -P without profile name:

Crash: Firefox.exe -P
No crash: Firefox.exe -P default

Comment 2

[Alice0775 White]

bp-f8ae611c-2cc8-4285-9895-8228c2130419

Comment 3

[Alice0775 White]

bp-cb792cfc-97dd-47bb-b0b6-e99fd2130419 on Ubuntu

Comment 4

[Ed Lee :Mardak]

Seems like anything triggering the profile manager causes the crash. Updating title for various ways to trigger the profile manager.

Comment 5

[Bobby Holley (:bholley)]

So, the problem here is that the ProfileManager uses nsWindowWatcher without ever having spun up the layout module, which means that we crash when trying to manipulate the JSContext stack via nsContentUtils, because nobody's yet called nsContentUtils::Init.

After discussing this with bsmedberg, it seems like the simplest thing to do is just to force the initialization of layout during XPCOM startup by getting a random service that's hooked into the layout module.

With this patch, I reliably hit an assertion at shutdown here: http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/pthreads/ptthread.c#266

I'm kind of stumped. I just managed to reproduce the assertion on a build without this patch, but it's much less reliable.

Comment 6

[Bobby Holley (:bholley)]

Attachment: Force layout initialization in XPCOM initialization. v1

Comment 7

[Bobby Holley (:bholley)]

Stack:

Thread 4 Crashed:: JS GC Helper
0   libsystem_kernel.dylib        	0x00007fff89c69ce2 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff80e1b7d2 pthread_kill + 95
2   libsystem_c.dylib             	0x00007fff80e0ca7a abort + 143
3   libnss3.dylib                 	0x00000001011f91ed PR_Assert + 109
4   libnss3.dylib                 	0x000000010121dd40 pt_AttachThread + 176
5   libnss3.dylib                 	0x000000010121d709 PR_GetCurrentThread + 73
6   XUL                           	0x00000001052c50e9 js::GCHelperThread::onBackgroundThread() + 25
7   XUL                           	0x00000001052c4eca js::gc::ArenaHeader::checkSynchronizedWithFreeList() const + 202
8   XUL                           	0x000000010528ed25 js::gc::ArenaHeader::getFirstFreeSpan() const + 21
9   XUL                           	0x00000001052f8ffd bool js::gc::Arena::finalize<js::BaseShape>(js::FreeOp*, js::gc::AllocKind, unsigned long) + 1421
10  XUL                           	0x00000001052dc4eb _ZL19FinalizeTypedArenasIN2js9BaseShapeEEbPNS0_6FreeOpEPPNS0_2gc11ArenaHeaderERNS4_9ArenaListENS4_9AllocKindERNS0_11SliceBudgetE + 107
11  XUL                           	0x00000001052c7e7e _ZL14FinalizeArenasPN2js6FreeOpEPPNS_2gc11ArenaHeaderERNS2_9ArenaListENS2_9AllocKindERNS_11SliceBudgetE + 190
12  XUL                           	0x00000001052c7ab6 js::gc::ArenaLists::backgroundFinalize(js::FreeOp*, js::gc::ArenaHeader*, bool) + 230
13  XUL                           	0x00000001052ccae7 _ZL21SweepBackgroundThingsP9JSRuntimeb + 199
14  XUL                           	0x00000001052cb9c4 js::GCHelperThread::doSweep() + 100
15  XUL                           	0x00000001052cb769 js::GCHelperThread::threadLoop() + 169
16  XUL                           	0x00000001052cb6b7 js::GCHelperThread::threadMain(void*) + 39
17  libnss3.dylib                 	0x000000010121faa3 _pt_root + 355
18  libsystem_c.dylib             	0x00007fff80e198bf _pthread_start + 335
19  libsystem_c.dylib             	0x00007fff80e1cb75 thread_start + 13

Comment 8

[Bobby Holley (:bholley)]

Comment on attachment 739727 [details] [diff] [review]
Force layout initialization in XPCOM initialization. v1

I think this was actually just the result of sharing profiles between a build from today and a build from monday. The problem doesn't reproduce with a fresh profile.

Flagging for review on this patch.

Comment 9

[Bobby Holley (:bholley)]

Landed directly to m-c, since we may want to respin Nightlies with this:

https://hg.mozilla.org/mozilla-central/rev/c74f44828165

Comment 10

[Bobby Holley (:bholley)]

This caused make check orange, so I had to back it out. I'm backing out the original offending changeset as well so that the startup crashes go away. I'll sort it out on monday.

https://hg.mozilla.org/mozilla-central/rev/797eeb4f147a

Comment 11

[Wayne Mery (:wsmwk)]

verified gone for Thunderbird. 20130419031000 is last build to crash

Comment 12

[u279076]

Alice, can you confirm this is fixed for you with Firefox 23b1?
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/23.0b1-candidates/build1/

Comment 13

[Alice0775 White]

I cannot reproduce the crash any more.
http://hg.mozilla.org/releases/mozilla-beta/rev/77a8241ae55d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 ID:20130625125232
http://hg.mozilla.org/releases/mozilla-beta/rev/77a8241ae55d
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20100101 Firefox/23.0 ID:20130625125232

Comment 14

[u279076]

Thanks Alice, marking this verified fixed.