JSStructuredCloneWriter leaks memory

RESOLVED FIXED in mozilla6

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: jseward, Assigned: Justin Lebar (not reading bugmail))

Tracking

(Depends on: 1 bug, {mlk, regression})

Trunk
mozilla6
x86_64
Linux
mlk, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox5 unaffected)

Details

(Whiteboard: bz nominated near comment 1)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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
tracking-firefox6: --- → ?
Keywords: mlk
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Keywords: regression
Blocks: 640452
(Assignee)

Comment 2

6 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

6 years ago
Created attachment 532414 [details] [diff] [review]
Patch v1
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+
(Assignee)

Comment 5

6 years ago
FWIW, JS_free is what JSAutoStructuredCloneBuffer::clear uses.
CC'ing pbiggar (see comment 4).

Comment 7

6 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

6 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

6 years ago
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.
Attachment #532535 - Flags: review?(igor)
(Assignee)

Updated

6 years ago
Attachment #532414 - Attachment is obsolete: true
Attachment #532414 - Flags: review?(pbiggar)

Updated

6 years ago
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|.  :(
(Assignee)

Comment 11

6 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?
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

6 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

6 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

6 years ago
status-firefox5: --- → unaffected
(Assignee)

Comment 15

6 years ago
Pushed followup to use JS_free instead of free.

http://hg.mozilla.org/mozilla-central/rev/794c73cbfca6
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Depends on: 657458
Blocks: 659858
No longer blocks: 640452
Target Milestone: --- → mozilla6

Updated

6 years ago
Whiteboard: bz nominated near comment 1

Comment 16

6 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

6 years ago
Assignee: nobody → justin.lebar+bug
You need to log in before you can comment on or make changes to this bug.