STR: I don't know specifically. These were picked up during a complete run of Mochitests on Valgrind. I don't know which test caused them. I can try to narrow it down. 3,008 bytes in 47 blocks are definitely lost in loss record 8,069 of 8,258 at 0x4C27972: realloc (vg_replace_malloc.c:525) by 0x66CD047: js::Vector<unsigned long, 0ul, js::ContextAllocPolicy>::growStorageBy(unsigned long) (jsutil.h:249) by 0x66CADCD: js::SCOutput::write(unsigned long) (jsvector.h:643) by 0x66CAE7F: JSStructuredCloneWriter::writeString(unsigned int, JSString*) (jsclone.cpp:362) by 0x66CBBA2: JSStructuredCloneWriter::write(js::Value const&) (jsclone.cpp:577) by 0x66CC196: js::WriteStructuredClone(JSContext*, js::Value const&, unsigned long**, unsigned long*, JSStructuredCloneCallbacks const*, void*) (jsclone.cpp:57) by 0x66AF7D7: JS_WriteStructuredClone (jsapi.cpp:5587) by 0x5C46AE1: nsStructuredCloneContainer::InitFromVariant(nsIVariant*, JSContext*) (nsStructuredCloneContainer.cpp:91) by 0x6048565: nsDocShell::AddState(nsIVariant*, nsAString_internal const&, nsAString_internal const&, int, JSContext*) (nsDocShell.cpp:9477) by 0x5C276F9: nsHistory::ReplaceState(nsIVariant*, nsAString_internal const&, nsAString_internal const&, JSContext*) (nsHistory.cpp:337) by 0x6477C31: NS_InvokeByIndex_P (xptcinvoke_x86_64_unix.cpp:195) by 0x5F7721F: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (xpcwrappednative.cpp:3141) plus two other reports, essentially identical.
As far as I can tell, nsStructuredCloneContainer::InitFromVariant is just buggy. It never frees jsBytes! Am I just missing something? Justin? Jonas?
(In reply to comment #1) > As far as I can tell, nsStructuredCloneContainer::InitFromVariant is just > buggy. It never frees jsBytes! Indeed! I'll post a fix in a moment.
Created attachment 532414 [details] [diff] [review] Patch v1
Comment on attachment 532414 [details] [diff] [review] Patch v1 Those are the right places to call free(), but I can't tell whether this is the right free() to call. The jsapi docs claim that js::Foreground::free is the right thing, but is that public? The JS_free calls you're making here can end up on the background thread (or in the foreground, depending on how the JSContext feels today). Paul, what's the story here?
FWIW, JS_free is what JSAutoStructuredCloneBuffer::clear uses.
CC'ing pbiggar (see comment 4).
It's acceptable (though sometimes not ideal) to call any of the free() methods on any allocated memory. That we don't expose these calls into the API would be a bug, except that we need to clarify how we use deallocators, and what their semantics are, which Igor is doing in bug 647103. (Igor, please correct me if I'm wrong here).
(In reply to comment #7) > It's acceptable (though sometimes not ideal) to call any of the free() > methods on any allocated memory. The code should call Foreground::free or free as it is not invoked from the finalizer. So JS_free should be avoided as it just consumes useless cycles checking for the finalization. > That we don't expose these calls into the API would be a bug, except that we > need to clarify how we use deallocators, and what their semantics are, which > Igor is doing in bug 647103. Well, with the background finalization we may not need any background free for the GC and may well end up using a single wrapper for the free in the engine. But that is for latter. For now I would suggest just to call free.
Created attachment 532535 [details] [diff] [review] Patch v2 s/JS_free/free, and verified that the leak doesn't appear when I run test_bug500328.html under valgrind.
Comment on attachment 532535 [details] [diff] [review] Patch v2 I think we really do want JS_free here; there's no guarantee that the |free| in libmozjs and libxul is the same |free|. :(
http://hg.mozilla.org/mozilla-central/rev/1ba51bb439e0 :) Would you like me to push a followup, or would you like someone else to weigh in first?
Push a followup with a FIXME comment explaining why it's JS_free and file a bug to update to Foreground::free once that's exposed?
(In reply to comment #9) > s/JS_free/free, and verified that the leak doesn't appear when I run > test_bug500328.html under valgrind. Also verified here. Can we get this in Fx 5 ? This is the second largest leak in mochitests, after bug 655435.
nsStructuredCloneContainer was added in rev 0221eb8660f4 on April 24. That's after the Aurora 5 branch on April 12 (tag a95d42642281).
Pushed followup to use JS_free instead of free. http://hg.mozilla.org/mozilla-central/rev/794c73cbfca6
unsetting request because this appears to have landed before the aurora migration. if it's not, please nominate the patch.