Closed Bug 624186 Opened 11 years ago Closed 9 years ago

Arguments.callee.caller leaks a docshell, window, etc when spanning a JSM boundary


(Core :: XPConnect, defect)

Not set





(Reporter: clever, Unassigned)



(Keywords: memory-leak, regression, Whiteboard: [MemShrink:P3])


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20110108 Firefox/4.0b9pre
Build Identifier: 

using arguments.callee.caller from a JSM can trigger an xpcom leak

 => mAllocCount:          58343
 => mReallocCount:         2921
 => mFreeCount:           51739  --  LEAKED 6604 !!!
 => mAdoptCount:           1873
 => mAdoptFreeCount:       1871  --  LEAKED 2 !!!

Reproducible: Always

Steps to Reproduce:
1. install the attached .xpi on a debug build of firefox
2. close firefox
3. look at stdout

--enable-application=browser --enable-debug --enable-jemalloc --enable-optimize=-O2
Built from
Attachment #502287 - Attachment mime type: application/octet-stream → text/plain
Component: General → XPConnect
Product: Firefox → Core
QA Contact: general → xpconnect
Ever confirmed: true
Summary: refcount leak jsm arguments callee caller → Arguments.callee.caller leaks when spanning a JSM boundary
Here's what's in the XPI.

modules/debuger.js, in its entirety:
> var EXPORTED_SYMBOLS = [ 'get_debug' ];
> function MAIN_debug () {
>         arguments.callee.caller;
> }
> function get_debug() {
>         return function local_debug() {
>                 dump(arguments.callee.caller);
>                 MAIN_debug();
>                 dump('leaking');
>         }
> }

A script in chrome/overlay.xul does this:
>  function crash() {
>    var debuger = Components.utils.import("resource://earthangel/debuger.js");
>    var debug = debuger.get_debug('foo');
>    debug('test');
>  }
>  crash();

(Clever confirmed for me that despite its name, this function doesn't crash; it just leaks.)

Apart from the usual boilerplate, that's it.
jorendorff, should this block (hard, soft, or 2.x)?
(In reply to comment #4)
> jorendorff, should this block (hard, soft, or 2.x)?

Let's ask this question officially!
blocking2.0: --- → ?
Keywords: mlk
Summary: Arguments.callee.caller leaks when spanning a JSM boundary → Arguments.callee.caller leaks a docshell, window, etc when spanning a JSM boundary
njn/jorendorff - drivers need more info to understand blocking here. How frequently would the leak be encountered, how painful, is it a regression?
Andreas, Blake, should this block?
I know nothing about this bug. Comment 3 was just me being nice. :) Sorry.
I don't know anything about this code and jorendorff told me he doesn't either, so Andreas or Blake will need to decide.
Is this a regression?
Keywords: qawanted
Andreas says this is liveable if it's not a regression, but we don't know yet. Who can determine that and re-nom if so?
blocking2.0: ? → -
Keywords: qawanted
I can do that tonight if nobody beats me to it.
This is a bit odd, overlaying browser.xul is essential to the leak.  I've reduced this to a testcase, looking for a known good build now.
This is a regression from 3.6.  Continuing to bisect.
blocking2.0: - → ?
Keywords: regression
with my past testing, i couldnt get it to leak multiple times, so it wont snowball out of control and use up all ram
Comment 15 is bogus, this is not a regression from 3.6.  The behavior of the test suite changed such that the test does not leak before, but the extension version leaks on 3.6.
blocking2.0: ? → ---
No longer blocks: mlk2.0
No longer blocks: mlk-fx5+
Whiteboard: [MemShrink:P3]
Build identifier: Mozilla/5.0 (X11; Linux i686; rv:25.0) Gecko/20130711 Firefox/25.0

WFM on the above build (latest Nightly) with the steps from bug description. Please reopen if it occurs again.
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.