This is related to bug 379491. Might even be the same. valgrind is telling me: ==5993== Invalid free() / delete / delete[] ==5993== at 0x400525D: free (vg_replace_malloc.c:233) ==5993== by 0x41088C9: free (nsTraceMalloc.c:1813) ==5993== by 0x470CBA2: PR_Free (prmem.c:490) ==5993== by 0x469EDC1: NS_Free_P (nsMemoryImpl.cpp:303) ==5993== by 0x4F6126B: nsMemory::Free(void*) (nsMemory.h:74) ==5993== by 0x4FC9F62: ReadScriptFromStream(JSContext*, nsIObjectInputStream*, JSScript**) (mozJSComponentLoader.cpp:406) ==5993== by 0x4FCD245: mozJSComponentLoader::ReadScript(nsIFastLoadService*, char const*, nsIURI*, JSContext*, JSScript**) (mozJSComponentLoader.cpp:974) ==5993== by 0x4FCE028: mozJSComponentLoader::GlobalForLocation(nsILocalFile*, JSObject**, char**) (mozJSComponentLoader.cpp:1114) ==5993== by 0x4FCB4C8: mozJSComponentLoader::LoadModule(nsILocalFile*, nsIModule**) (mozJSComponentLoader.cpp:598) ==5993== by 0x46853CE: nsFactoryEntry::GetFactory(nsIFactory**) (nsComponentManager.cpp:3577) ==5993== by 0x4680643: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1795) ==5993== by 0x460FAA1: CallCreateInstance(char const*, nsISupports*, nsID const&, void**) (nsComponentManagerUtils.cpp:167) ==5993== Address 0x66AAE58 is 0 bytes inside a block of size 824 free'd ==5993== at 0x400525D: free (vg_replace_malloc.c:233) ==5993== by 0x41088C9: free (nsTraceMalloc.c:1813) ==5993== by 0x470CBA2: PR_Free (prmem.c:490) ==5993== by 0x469EDC1: NS_Free_P (nsMemoryImpl.cpp:303) ==5993== by 0x5129131: nsMemory::Free(void*) (nsMemory.h:74) ==5993== by 0x512BB28: nsTranscodeJSPrincipals(JSXDRState*, JSPrincipals**) (nsJSPrincipals.cpp:152) ==5993== by 0x45483B0: js_XDRScript (jsscript.c:674) ==5993== by 0x44E2CD7: fun_xdrObject (jsfun.c:1452) ==5993== by 0x4516609: js_XDRObject (jsobj.c:4730) ==5993== by 0x4554A61: XDRValueBody (jsxdrapi.c:560) ==5993== by 0x4554CB9: js_XDRAtom (jsxdrapi.c:635) ==5993== by 0x4547DD2: XDRAtomMap (jsscript.c:488) it looks like the failure to deserialize a principal (which might need its own bug) causes JS_XDRScript to return false under ReadScriptFromStream. So we never reset |data| to whatever is in the xdr, andthen free it. Except it's already been freed by the nsTranscodeJSPrincipals code. This is basically blocking debugging for me, because my build simply won't start.

Comment on attachment 271705 [details] [diff] [review] This should fix it Shaver and I were r+sr tweedle-dee and -dum (I was -dum) on bryner's original patch. Sigh. /be

Fixed.

Comment on attachment 271705 [details] [diff] [review] This should fix it I think it's worth taking this on branch. This is a fix to properly clean up when fastload fails for some reason; the main benefit is avoiding the double-free. I doubt this happens much on branch, but just to be safe.... I think this is a very safe fix.

Comment on attachment 271705 [details] [diff] [review] This should fix it approved for 1.8.1.7, a=dveditz for release-drivers

Fixed on branch.