Closed Bug 793533 Opened 7 years ago Closed 6 years ago

Valgrind on tbpl detects leak at malloc (392 or 1,368 bytes in 1 blocks are definitely lost) with xpc::CreateGlobalObject on the stack

Categories

(Core :: XPConnect, defect, major)

x86_64
Linux
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gkw, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: memory-leak, valgrind)

Attachments

(2 files, 2 obsolete files)

Attached file Valgrind stack (obsolete) —
Valgrind detects a leak of 392 bytes at malloc with xpc_CreateGlobalObject on the stack, see attached snippet which comes from:

https://tbpl.mozilla.org/php/getParsedLog.php?id=15457865&tree=Firefox&full=1
Hardware: All → x86_64
Line numbers would be useful here :-/
No longer blocks: valgrind-on-tbpl
Attachment #663860 - Attachment is obsolete: true
> Line numbers would be useful here :-/

We now have line numbers. For example,

http://hg.mozilla.org/mozilla-central/file/ca4af4af5334/js/xpconnect/src/XPCWrappedNative.cpp#l320

seems to point correctly to the call to xpc_CreateGlobalObject.
Keywords: mlk
> This one is 64-bit only. This appeared in the following window:
> 
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=85dd8e346102&tochange=635fcc11d2b1

Bobby, Ms2ger, is bug 795300 likely the cause?
No. Bug 793116 is ever so slightly more likely, but even that shouldn't have caused leaks.
(In reply to :Ms2ger from comment #7)
> Could I have broken
> <https://hg.mozilla.org/mozilla-central/file/965f6dc789be/build/valgrind/
> cross-architecture.sup#l57> with the rename, though?

Possibly. I'll land a fix to remove that and see if it still shows up again.
> Possibly. I'll land a fix to remove that and see if it still shows up again.

https://hg.mozilla.org/mozilla-central/rev/1a2f506b1a92
Summary: Valgrind on tbpl detects leak at malloc (392 bytes in 1 blocks are definitely lost) with xpc_CreateGlobalObject on the stack → Valgrind on tbpl detects leak at malloc (392 bytes in 1 blocks are definitely lost) with xpc::CreateGlobalObject on the stack
Attachment #664983 - Attachment is obsolete: true
Summary: Valgrind on tbpl detects leak at malloc (392 bytes in 1 blocks are definitely lost) with xpc::CreateGlobalObject on the stack → Valgrind on tbpl detects leak at malloc (392 or 1,368 bytes in 1 blocks are definitely lost) with xpc::CreateGlobalObject on the stack
Valgrind also detected a leak of 1,368 bytes (direct) with xpc::CreateGlobalObject on the stack, see attached snippet which comes from:

https://tbpl.mozilla.org/php/getParsedLog.php?id=17064538&tree=Firefox&full=1

m-c changeset rev is a761bfc192b5.

It didn't happen in the previous Valgrind run here: https://tbpl.mozilla.org/?noignore=1&jobname=valgrind&rev=dd68409d7810

So I'm guessing the regression range is:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd68409d7810&tochange=a761bfc192b5
This is no longer occurring in Valgrind-on-TBPL runs.  I think this one was a false positive due to the storing of pointers as js::Values, as fixed by bug 940069.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.