575729 - Crash in Crashreporter in mochitest

Status: RESOLVED DUPLICATE of bug 578952

(Core :: Layout, defect)

Description

[Benedict Hsieh [:benedict]]

I get this crash in the child process of a mochitest:

Program received signal SIGSEGV, Segmentation fault.
0x00007f6d9d04ecb0 in nsTHashtable<nsBaseHashtableET<nsCStringHashKey, nsCString> >::PutEntry (this=0x0, aKey=...) at ../../dist/include/nsTHashtable.h:182
182	    NS_ASSERTION(mTable.entrySize, "nsTHashtable was not initialized properly.");
(gdb) up
#1  0x00007f6d9d04e411 in nsBaseHashtable<nsCStringHashKey, nsCString, nsCString>::Put (this=0x0, aKey=..., aData=...)
    at ../../dist/include/nsBaseHashtable.h:163
163	    EntryType* ent = PutEntry(aKey);
(gdb) up
#2  0x00007f6d9d04aebb in CrashReporter::AnnotateCrashReport (key=..., 
    data=...)
    at /home/bhsieh/electrolysis/toolkit/crashreporter/nsExceptionHandler.cpp:887
887	  nsresult rv = crashReporterAPIData_Hash->Put(key, escapedData);
(gdb) up
#3  0x00007f6d9d023cb7 in nsXULAppInfo::AnnotateCrashReport (
    this=0x7f6d9f7d6cf0, key=..., data=...)
    at /home/bhsieh/electrolysis/toolkit/xre/nsAppRunner.cpp:967
967	  return CrashReporter::AnnotateCrashReport(key, data);
(gdb) up
#4  0x00007f6d9d33a6fd in ARENA_POISON_init ()
    at /home/bhsieh/electrolysis/layout/base/nsPresArena.cpp:238
238	                            nsPrintfCString(17, "%.16llx", PRUint64(rgnbase)));
(gdb) up
#5  0x00007f6d9c3d7df8 in PR_CallOnce (once=0x7f6d9f7e4440, 
    func=0x7f6d9d33a5ba <ARENA_POISON_init>)
    at /home/bhsieh/electrolysis/nsprpub/pr/src/misc/prinit.c:807
807		    once->status = (*func)();
Current language:  auto
The current source language is "auto; currently c".
(gdb) up
#6  0x00007f6d9d33ae39 in State (this=0x7f6d8c28fa50)
    at /home/bhsieh/electrolysis/layout/base/nsPresArena.cpp:289
289	    PR_CallOnce(&ARENA_POISON_guard, ARENA_POISON_init);

Will post follow-up with steps to reproduce.

Comment 1

[Benedict Hsieh [:benedict]]

Attachment: enables test that causes this

Just enables a mochitest that is already in the tree. I think this is caused by the loadFrameScript() call, in testing just doing 
>loadFrameScript("data:,dump('hello world')", true); 
would cause this.

Comment 2

[Benedict Hsieh [:benedict]]

From IRC, for myself or someone who takes this on:

>zwol: benedict: suggest running this under the debugger, breakpointing in SetExceptionHandler, stepping to the point where crashReporterAPIData_Hash ceases to be null, then doing 'watch crashReporterAPIData_Hash' and continuing.
> zwol: because *something* is setting it back to null without clearing gExceptionHandler.

Comment 3

[Benedict Hsieh [:benedict]]

Although the patch hasn't been merged to e10s yet. Confirmed that patch in other bug does resolve this issue, though.