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

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Valgrind stack

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

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Line numbers would be useful here :-/

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: m-c changeset ca4af4af5334 Valgrind stack with line numbers

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> 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.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: m-c changeset 635fcc11d2b1 Valgrind stack with line numbers

This one is 64-bit only. This appeared in the following window:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85dd8e346102&tochange=635fcc11d2b1

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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

Comment 6

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

No. Bug 793116 is ever so slightly more likely, but even that shouldn't have caused leaks.

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Could I have broken <https://hg.mozilla.org/mozilla-central/file/965f6dc789be/build/valgrind/cross-architecture.sup#l57> with the rename, though?

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> 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

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: m-c changeset a761bfc192b5 Valgrind stack with line numbers

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

Comment 11

[Nicholas Nethercote [inactive]]

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.