Memory leak in SC.ScrollView [chrome] #840

dcporter opened this Issue Sep 28, 2012 · 2 comments


None yet

1 participant

SproutCore member

What it says in the subject. I'm working on a fix, but it's a complex view with lots of cross-references and no kind of custom destroy method, so it'll take me a bit. Repro instructions are below; I'd appreciate anyone able to poke a hole in them to do so.

The Science:

1) sc-init TestCase
2) Replace the new app's main_page.js with this:

TestCase.mainPage ={

  // The main pane is made visible on screen as soon as your app is loaded.
  // Add childViews to this pane for views to display immediately on page 
  // load.
    childViews: 'buttonView'.w(),

      layout: { centerX: 0, centerY: 0, height: 24, width: 80 },

      testObject: null,

      title: function() {
        return this.get('testObject') ? 'Object' : 'null';

      action: function() {
        if (!this.get('testObject')) {
          this.set('testObject', SC.Object.create());
        } else {
          this.set('testObject', null);


This gives you a button which creates and destroys an instance of your choice of class.

3) Open the app in Chrome; open up the console (⌘+Option+J); open up Profiles and select Take Heap Snapshot.
4) Click "Start" or the black circle at the bottom to take a snapshot. (We are currently testing SC.Object.) In the snapshot, note the Objects Count for SC.Object. I see 11.
5) Click the app's "null" button. It should change to "Object".
6) Take another snapshot, and note the object count for SC.Object - I see 12.
7) Click the app's button again to set it back to "null".
8) Take another snapshot, and note that the object count for SC.Object has gone back down to 11. No memory leak.

9) In main_page.js, replace SC.Object (on the line "this.set('testObject', SC.Object.create());") with SC.View. Repeat steps 4 - 8 above, but this time note that the object count for "ret" instead. ("ret" is the category SC.View ends up under; you can verify this in the console, just, not right now or you'll mess up your numbers.) For me, the numbers go from 22, to 24 (thanks to LayoutStyleCalculator) back to 22. No memory leak.

10) Now replace SC.View with SC.ScrollView and repeat. The "ret" numbers go from 22 to 30, but then they stay at 30. They'll keep increasing every time you toggle the button. Memory leak!

SproutCore member

Hmm... actually, oddly, ret only goes up as high as 38 and then tops off.

SproutCore member

Uncollected objects were going between 8 and 10. In pull request #841 I've got it down to three thanks to a couple of approaches. The last three look like they're binding issues... which may require its own Issue and a serious effort. I'll keep looking.

@dcporter dcporter closed this Sep 28, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment