Closed Bug 387572 Opened 14 years ago Closed 14 years ago

Invalid free deserializing JS component script

Categories

(Core :: XPConnect, defect)

x86
Linux
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

(Keywords: fixed1.8.1.8)

Attachments

(1 file)

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.
Flags: blocking1.9?
Attachment #271705 - Flags: review?
Attachment #271705 - Flags: review? → review?(brendan)
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
Attachment #271705 - Flags: superreview+
Attachment #271705 - Flags: review?(brendan)
Attachment #271705 - Flags: review+
Fixed.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → 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.
Attachment #271705 - Flags: approval1.8.1.6?
Comment on attachment 271705 [details] [diff] [review]
This should fix it

approved for 1.8.1.7, a=dveditz for release-drivers
Attachment #271705 - Flags: approval1.8.1.7? → approval1.8.1.7+
Fixed on branch.
Keywords: fixed1.8.1.7
Flags: in-testsuite?
Assignee: nobody → bzbarsky
You need to log in before you can comment on or make changes to this bug.