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.

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.

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.

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