Closed
Bug 656991
Opened 13 years ago
Closed 13 years ago
JSStructuredCloneWriter leaks memory
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla6
Tracking | Status | |
---|---|---|
firefox5 | --- | unaffected |
People
(Reporter: jseward, Assigned: justin.lebar+bug)
References
(Depends on 1 open bug)
Details
(Keywords: memory-leak, regression, Whiteboard: bz nominated near comment 1)
Attachments
(1 file, 1 obsolete file)
1.08 KB,
patch
|
igor
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•13 years ago
|
||
As far as I can tell, nsStructuredCloneContainer::InitFromVariant is just buggy. It never frees jsBytes! Am I just missing something? Justin? Jonas?
Updated•13 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Updated•13 years ago
|
Keywords: regression
Assignee | ||
Comment 2•13 years ago
|
||
(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.
Assignee | ||
Comment 3•13 years ago
|
||
Attachment #532414 -
Flags: review?(bzbarsky)
Comment 4•13 years ago
|
||
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?
Attachment #532414 -
Flags: review?(pbiggar)
Attachment #532414 -
Flags: review?(bzbarsky)
Attachment #532414 -
Flags: review+
Assignee | ||
Comment 5•13 years ago
|
||
FWIW, JS_free is what JSAutoStructuredCloneBuffer::clear uses.
Comment 7•13 years ago
|
||
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).
Comment 8•13 years ago
|
||
(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.
Assignee | ||
Comment 9•13 years ago
|
||
s/JS_free/free, and verified that the leak doesn't appear when I run test_bug500328.html under valgrind.
Attachment #532535 -
Flags: review?(igor)
Assignee | ||
Updated•13 years ago
|
Attachment #532414 -
Attachment is obsolete: true
Attachment #532414 -
Flags: review?(pbiggar)
Updated•13 years ago
|
Attachment #532535 -
Flags: review?(igor) → review+
Comment 10•13 years ago
|
||
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|. :(
Assignee | ||
Comment 11•13 years ago
|
||
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?
Comment 12•13 years ago
|
||
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?
Reporter | ||
Comment 13•13 years ago
|
||
(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.
Assignee | ||
Comment 14•13 years ago
|
||
nsStructuredCloneContainer was added in rev 0221eb8660f4 on April 24. That's after the Aurora 5 branch on April 12 (tag a95d42642281).
Assignee | ||
Updated•13 years ago
|
status-firefox5:
--- → unaffected
Assignee | ||
Comment 15•13 years ago
|
||
Pushed followup to use JS_free instead of free. http://hg.mozilla.org/mozilla-central/rev/794c73cbfca6
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Target Milestone: --- → mozilla6
Updated•13 years ago
|
Whiteboard: bz nominated near comment 1
Comment 16•13 years ago
|
||
unsetting request because this appears to have landed before the aurora migration. if it's not, please nominate the patch.
tracking-firefox6:
? → ---
Updated•13 years ago
|
Assignee: nobody → justin.lebar+bug
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•