Closed Bug 656991 Opened 9 years ago Closed 9 years ago

JSStructuredCloneWriter leaks memory

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
Linux
defect
Not set

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)

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?
Blocks: 551225
Keywords: mlk
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
(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.
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #532414 - Flags: review?(bzbarsky)
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+
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.
Attached patch Patch v2Splinter Review
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)
Attachment #532414 - Attachment is obsolete: true
Attachment #532414 - Flags: review?(pbiggar)
Attachment #532535 - Flags: review?(igor) → review+
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
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Depends on: 657458
No longer blocks: mlk-fx5+
Target Milestone: --- → mozilla6
Whiteboard: bz nominated near comment 1
unsetting request because this appears to have landed before the aurora migration. if it's not, please nominate the patch.
Assignee: nobody → justin.lebar+bug
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.