Trying to chase memory leak but cannot understand retaining tree....

[Robert Slaney]

Can someone please help me understand how to read this retaining tree ( sorry for the text view, I'm unable to insert image due to corporate policies ).  The "grid" object should no longer be available but it is being kept alive by the following tree.

grid in system / Context @576113

    context in function() @576117

        4 in @632133

            66 in (code) @261183

                code in function() @ 261805

                    Row in @36853

                        kg in Window / localhost @2827

Distance of "grid" is 7, kg in Window is 1.

The functions above are from the koGrid library, although slightly modified.

The function referred to by @261805 is declared as window.kg.Row = function(entity, config, selectionService, prevRow) { ... }.  This is used as a constructor function and is instantiated using "new window.kg.Row(...)"

The function referred to by @576117 is a function attached to the selectionService instance ("setSelection").

Observations:

@36853 refers to the "kg" object in Window.  This is where all the constructor functions are declared ( see below )

The context in function() refers to the closure over the SelectionService constructor function in which grid is the sole argument.

The setSelection function is an anonymous function attached to an instance of SelectionService ( see below ) and is only ever created/declare when executing the SelectionService constructor.

Assumptions

@261805 refers to the Row constuctor function in the kg object, NOT the instance of an individual Row constructed by using new window.kg.Row()

@576117 refers to the anonymous function setSelection

Questions...

What does "66 in (code)" refer to ?  I get "not available" if I hover over this.  

What does "4 in @632133" refer to ?  I also get "not available" if I hover over this.

How did I get from a constructor function definition to an instance context of function setSelection @576117

If entity @261805 is not the constructor definition and is in actuality an instance reference of Row, then what is linking that to window.kg.Row

Changing the order of the lines of code in the Row constructor function then 66 appears to refer to the line of code  (which also happens to be the 33th line of code )

   "self.selectionService.setSelection(self, self.entity[SELECTED_PROP]);"

Inserting a line immediately above this "moves" 66 in code to 68 in code.  Inserting any line of code AFTER this line does not change the value of 66.

Here is a cut down version of the code involved in this tree.

window.kg.Grid = function() {

    var self = this;

    self.SelectionService = new window.kg.SelectionService(self);

}

window.kg.SelectionService = function(grid) {

    var self = this;

    self.setSelection = function(rowItem, isSelected) {

        ...

    }

}

window.kg.Row = function( entity, config, selectionService, prevRow ) {

    var self = this;

    self.selectionService = selectionService;

    ...

    self.selectionService.setSelection( self, self.entity[SELECTED_PROP] );

    ...

}

[Yury Semikhatsky]

[+ulan from V8 team who worked on fixing leaks through references in code objects]

Hi Robert,

This might be a leak through references in optimized code. The thing is that V8 keeps references to some objects right in the compiled code. Normally the code objects should be evetually GCed and shouldn't cause leaks but we've seen a few bugs where that happened. Can you please start Chrome with --js-flags="--nocrankshaft --noopt" command line flag and check that this retaining path disappears?

Ulan, am I right that the references from the code objects are strong and it may happen that an object is retained  only by code? If so, when such object should be collected?

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/597bf2ab-0f24-43c0-84c5-5c9daa2bb05e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ulan Degenbaev]

> Ulan, am I right that the references from the code objects are strong and it may happen that an object is retained  only by code? If so, when such object should be collected?

Yes, there two kinds of known leaks via code objects in V8:

1) Optimized code can embed objects and keep them alive. This should be fixed in latest Chrome Canary (https://code.google.com/p/v8/source/detail?r=18616)

2) Unoptimized code can keep maps alive via monomorphic inline caches. This is an open issue.

If you have a test that reproduces a leak via code objects in latest Chrome Canary, please post it in https://code.google.com/p/v8/issues/detail?id=2073 and we will take a look.

Cheers,

Ulan.

[Robert Slaney]

Hi Yuri.

Thanks for taking the time to reply.  Starting chrome with those flags has not removed that retaining path.

Just to confirm I've started Chrome properly, I used the following commandline from an Administrative command window

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --js-flags="--nocrankshaft --noopt"

I've also seen quite a few detached DOM trees that are still being kept alive

native in HTMLSelectElement @354217

  [0] in jQuery.fn.jQuery.init @355967

    $element in system / Context @355963

      context in function() @355721

        25 in (map descriptors)[] @355717

         descriptors in system / Map @232699

           1 in (transition array)[] @232697

             transitions in system / Map @232703

               3906 in [] @303485

                 map_cache in system / NativeContext @205

I'm seeing many thousands of nodes being kept alive in detach trees with no apparent live Javascript references when navigating a few "pages" in our single page app.

[Robert Slaney]

Hi Ulan.

I'm still seeing the same retention page in 34.0.1799.0, although the numbers are a little different

grid in system / Context @421303

   context in function() @421309

     3 in @474327

       65 in (code for window.kg.Row) @379431

         code in function() @142499

           Row in @19993

             kg in Window / localhost/ @3525

[Yury Semikhatsky]

On Wed, Jan 22, 2014 at 11:59 PM, Robert Slaney <slan...@gmail.com> wrote:

Hi Yuri.

Thanks for taking the time to reply.  Starting chrome with those flags has not removed that retaining path.

Just to confirm I've started Chrome properly, I used the following commandline from an Administrative command window

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --js-flags="--nocrankshaft --noopt"

Correct, this is the command line that I meant.

 

I've also seen quite a few detached DOM trees that are still being kept alive

native in HTMLSelectElement @354217

  [0] in jQuery.fn.jQuery.init @355967

    $element in system / Context @355963

      context in function() @355721

        25 in (map descriptors)[] @355717

         descriptors in system / Map @232699

           1 in (transition array)[] @232697

             transitions in system / Map @232703

               3906 in [] @303485

                 map_cache in system / NativeContext @205

I'm seeing many thousands of nodes being kept alive in detach trees with no apparent live Javascript references when navigating a few "pages" in our single page app.

--

You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/fe665713-13ef-4950-bf8b-e69c4a218572%40googlegroups.com.