Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Animated progress bar memory leak in Chrome #14409

Closed
jeanrajotte opened this Issue Aug 16, 2014 · 29 comments

Comments

Projects
None yet
5 participants
@jeanrajotte
Copy link

jeanrajotte commented Aug 16, 2014

I leave getbootstrap.com opened for hours as I develop and go back for reference and I find the tab in Chrome is reporting massive memory consumption, increasing over time.

@cvrebert cvrebert added the js label Aug 16, 2014

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Aug 18, 2014

Did you try forcing a garbage collection? Chrome only does a garbage collection in certain circumstances, and until then it will appear that memory usage is ever increasing. If you force a GC and the page continues to increase its memory usage, then it could be a problem.

screen shot 2014-08-18 at 13 30 27

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Aug 21, 2014

Thanks. I'll do this the next time I see it happen. But still, it's
something happening to YOUR pages (site), none other, and I've got many
tabs (other sites) open for a long time...

Jean Rajotte
+1 647-525-4836

On 18 August 2014 16:33, Ross Allen notifications@github.com wrote:

Did you try forcing a garbage collection? Chrome only does a garbage
collection in certain circumstances, and until then it will appear that
memory usage is ever increasing. If you force a GC and the page continues
to increase its memory usage, then it could be a problem.

[image: screen shot 2014-08-18 at 13 30 27]
https://cloud.githubusercontent.com/assets/29612/3957564/b6e5e32a-2716-11e4-97e8-18f6064c6b2a.png


Reply to this email directly or view it on GitHub
#14409 (comment).

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Sep 8, 2014

Has anyone been able to reproduce this?

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Sep 8, 2014

@jeanrajotte Do you remember which page you were viewing when you revisited the tab and saw it with high memory usage?

@mdo I have a hunch the carousel leaks memory. If you visit http://getbootstrap.com/examples/carousel/, disable the carousel with $("#myCarousel").carousel("pause"), and manually cycle through the carousel, you can watch it consume a handful of bytes after each cycle that are never garbage collected. If you were to leave the JavaScript page open for hours with its two auto-cycling carousels, memory usage would slowly increase.

This needs more investigation, but from what I've seen: DOM nodes and listeners are correctly cleaned up. If you watch Chrome's Timeline, those numbers are constant even after cycling the carousel dozens of times.

The leak (if there is one) is likely JavaScript objects with circular references. My second hunch is the leak is coming from the nested closures created to listen for "bsTransitionEnd": https://github.com/twbs/bootstrap/blob/master/js/carousel.js#L150

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Sep 8, 2014

/cc @fat

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 8, 2014

I just let it sit on http://getbootstrap.com/components/ for about 40
minutes. It started near 90M and it's now at 756K. I run ghostery, in case
this makes a difference. It blocks:

carbon ads
gaug.es
twitter badge.

I could try it w/o ghostery if it helps find the leak...

J

Jean Rajotte
+1 647-525-4836

On 8 September 2014 18:33, Mark Otto notifications@github.com wrote:

/cc @fat https://github.com/fat


Reply to this email directly or view it on GitHub
#14409 (comment).

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Sep 8, 2014

/components doesn't have a carousel, so if there is a memory leak in the carousel it is unrelated.

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Sep 8, 2014

@jeanrajotte Yeah if you could diagnose without that extension enabled, that's be awesome.

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Sep 9, 2014

@jeanrajotte How are you judging that the page is using a lot of memory, and which operating system are you using?

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 9, 2014

Haven't removed Ghostery yet. Left it on the page all night w/o touching
anything. It's now at 3.5G.

I see this in Chrome's control panel for this one tab (out of 3).

Using Windows 7 Pro.

Will now try w/o Ghostery.

Jean Rajotte
+1 647-525-4836

On 8 September 2014 20:05, Ross Allen notifications@github.com wrote:

@jeanrajotte https://github.com/jeanrajotte How are you judging that
the page is using a lot of memory, and which operating system are you using?


Reply to this email directly or view it on GitHub
#14409 (comment).

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 9, 2014

Without Ghostery (i.e. adding the site to the whitelist),
http://getbootstrap.com/components/, as witnessed in Chrome's task manager,
steadily climbing, up to 555 Mb after ~30 minutes.

Jean Rajotte
+1 647-525-4836

On 9 September 2014 09:05, Jean Rajotte jean.rajotte@gmail.com wrote:

Haven't removed Ghostery yet. Left it on the page all night w/o touching
anything. It's now at 3.5G.

I see this in Chrome's control panel for this one tab (out of 3).

Using Windows 7 Pro.

Will now try w/o Ghostery.

Jean Rajotte
+1 647-525-4836

On 8 September 2014 20:05, Ross Allen notifications@github.com wrote:

@jeanrajotte https://github.com/jeanrajotte How are you judging that
the page is using a lot of memory, and which operating system are you using?


Reply to this email directly or view it on GitHub
#14409 (comment).

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 9, 2014

Now on to http://getbootstrap.com/javascript/. starts at around 44 Kb....

After about 1 hour, without any activity, it's at 101 Mb.

Jean Rajotte
+1 647-525-4836

On 9 September 2014 10:03, Jean Rajotte jean.rajotte@gmail.com wrote:

Without Ghostery (i.e. adding the site to the whitelist),
http://getbootstrap.com/components/, as witnessed in Chrome's task
manager, steadily climbing, up to 555 Mb after ~30 minutes.

Jean Rajotte
+1 647-525-4836

On 9 September 2014 09:05, Jean Rajotte jean.rajotte@gmail.com wrote:

Haven't removed Ghostery yet. Left it on the page all night w/o touching
anything. It's now at 3.5G.

I see this in Chrome's control panel for this one tab (out of 3).

Using Windows 7 Pro.

Will now try w/o Ghostery.

Jean Rajotte
+1 647-525-4836

On 8 September 2014 20:05, Ross Allen notifications@github.com wrote:

@jeanrajotte https://github.com/jeanrajotte How are you judging that
the page is using a lot of memory, and which operating system are you using?


Reply to this email directly or view it on GitHub
#14409 (comment).

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Sep 9, 2014

If you focus another tab and let the Bootstrap Components tab go to the background, what happens to the memory usage after a few minutes?

The "/components" page is constantly re-compositing layers because of the animated progress bar, and that takes some memory and CPU. Increasing memory usage itself is not necessarily a sign of a problem. If the window and the tab are in the foreground, your OS is going to give it the memory it wants and won't reclaim it until another process needs it.

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 9, 2014

shift-ctrl-r to /components (i.e. total refresh).

[11:38] : Chrome task manager reports ~140 Mb
[12:20] : Chrome task manager reports ~170 Mb

It climbs a lot faster with the page is focused than when it's not.
However, your notion that the OS will release the memory isn't sound. If I
leave it to climb, the OS reports the memory as used. In my 3 Gb example,
closing the tab release 3 Gb and I saw in Windows' task manager that RAM
went from 6 Gb down to 3 Gb.

I'll stop now, unless you request more specific tests. Thank you for
playing.

Jean Rajotte
+1 647-525-4836

On 9 September 2014 11:33, Ross Allen notifications@github.com wrote:

If you focus another tab and let the Bootstrap Components tab go to the
background, what happens to the memory usage after a few minutes?

The "/components" page is constantly re-compositing layers because of the
animated progress bar, and that takes some memory and CPU. Increasing
memory usage itself is not necessarily a sign of a problem. If the window
and the tab are in the foreground, your OS is going to give it the memory
it wants and won't reclaim it until another process needs it.


Reply to this email directly or view it on GitHub
#14409 (comment).

@cvrebert cvrebert changed the title your website looks like it has a leak... Memory leak? Sep 9, 2014

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 23, 2014

Meanwhile.....

I happen to let the page open as I needed the docs during developing. My
fan hasn't stopped working overnight.

1st attachment: The Chrome task manager. Notice the CPU is going on a page
just sitting there.

2nd attachment: Windows task manager: Top of the heap, king of the hill!

3rd attachment: Windows task manager for my computer in molasses now!. I
was due for a reboot anyway. :)

Having fun yet?

Jean

Jean Rajotte
+1 647-525-4836

On 9 September 2014 12:22, Jean Rajotte jean.rajotte@gmail.com wrote:

shift-ctrl-r to /components (i.e. total refresh).

[11:38] : Chrome task manager reports ~140 Mb
[12:20] : Chrome task manager reports ~170 Mb

It climbs a lot faster with the page is focused than when it's not.
However, your notion that the OS will release the memory isn't sound. If I
leave it to climb, the OS reports the memory as used. In my 3 Gb example,
closing the tab release 3 Gb and I saw in Windows' task manager that RAM
went from 6 Gb down to 3 Gb.

I'll stop now, unless you request more specific tests. Thank you for
playing.

Jean Rajotte
+1 647-525-4836

On 9 September 2014 11:33, Ross Allen notifications@github.com wrote:

If you focus another tab and let the Bootstrap Components tab go to the
background, what happens to the memory usage after a few minutes?

The "/components" page is constantly re-compositing layers because of the
animated progress bar, and that takes some memory and CPU. Increasing
memory usage itself is not necessarily a sign of a problem. If the window
and the tab are in the foreground, your OS is going to give it the memory
it wants and won't reclaim it until another process needs it.


Reply to this email directly or view it on GitHub
#14409 (comment).

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Sep 23, 2014

@jeanrajotte I don't see any attachments. Don't think GitHub supports email attachments in notification emails.

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 23, 2014

OK.
Basically, the attachments showed that the getbootstrap/components Chrome
tab had climbed to 2.5 Gb of RAM, was using 7-10% of the CPU for doing
nothing, that Windows memory was @ ~6.5 Gb, thrashing galore on a 4Gb
machine. For a documentation page, that's mighty wow!

I hope this helps.
J

Jean Rajotte
+1 647-525-4836

On 23 September 2014 09:18, Heinrich Fenkart notifications@github.com
wrote:

@jeanrajotte https://github.com/jeanrajotte I don't see any
attachments. Don't think GitHub supports email attachments in notification
emails.


Reply to this email directly or view it on GitHub
#14409 (comment).

@hnrch02 hnrch02 added the help wanted label Sep 23, 2014

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Sep 23, 2014

Could be the Youtube video?

@jeanrajotte

This comment has been minimized.

Copy link
Author

jeanrajotte commented Sep 23, 2014

Mark,
couldn't this be tested by merely opening the page URL that's in the iframe
and letting it sit in the browser for a while. I'm doing this now. I doubt
it's the issue, but let's see. The video isn't running, on its own or in
the components page.

Jean

Jean Rajotte
+1 647-525-4836

On 23 September 2014 15:53, Mark Otto notifications@github.com wrote:

Could be the Youtube video?


Reply to this email directly or view it on GitHub
#14409 (comment).

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Sep 23, 2014

If you disable JavaScript you will still see the memory usage increase due to the infinite keyframe animation on .progress-bar.active. If you remove the -webkit-animation definition from that selector, the memory usage never increases.

Why does an infinite animation infinitely drive up memory usage? I'm not sure. It seems like a problem the browser should be able to handle.

I did an unscientific test I'd like to prove that points to the alpha transparency of .progress-bar-striped class as the culprit. I redefined the color stops with opaque colors (alpha == 1), and the memory usage appeared to no longer increase.

If this is actually the problem, a solution would be to define the background gradient for each .progress-bar-striped.progress-bar-{warning,info,etc} combo with opaque background colors to forego infinite alpha compositing. I will try to come up with a test to prove this.

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Sep 23, 2014

Ahhh yeah, it's definitely the progress bar. Infinite animations always do this. It'd be nice to maybe add the class when that component is in the viewport instead of always having it on, as a workaround for now. Maybe someone could open a PR?

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Sep 23, 2014

Refs #13416.

@hnrch02

This comment has been minimized.

Copy link
Member

hnrch02 commented Sep 23, 2014

@mdo Maybe we should wait for @ssorallen's test and then go that route. I'd prefer a CSS-only solution.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Sep 23, 2014

hnrch02 added a commit that referenced this issue Oct 26, 2014

@mdo

This comment has been minimized.

Copy link
Member

mdo commented Oct 29, 2014

@cvrebert Care to bump the linked Chromium issue so we can close this out given our recent docs change?

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Oct 31, 2014

@mdo Not sure that's actually the same issue, so I went ahead and reported a new Chrome bug: https://code.google.com/p/chromium/issues/detail?id=429375

cvrebert added a commit that referenced this issue Nov 1, 2014

cvrebert added a commit that referenced this issue Nov 1, 2014

@cvrebert cvrebert changed the title Memory leak? Animated progress bar memory leak in Chrome Nov 1, 2014

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Nov 3, 2014

@ssorallen @jeanrajotte The Chrome folks need some more info. Would appreciate it if you could weigh in at https://code.google.com/p/chromium/issues/detail?id=429375

@ssorallen

This comment has been minimized.

Copy link
Contributor

ssorallen commented Nov 3, 2014

@cvrebert Thanks for opening the issue, and sorry I've been slow on this issue. I will see if I can answer their questions.

@cvrebert

This comment has been minimized.

Copy link
Member

cvrebert commented Nov 3, 2014

@ssorallen No worries! We're already quite grateful for the investigation you've done so far. 😄

@cvrebert cvrebert added confirmed css and removed help wanted js labels Jan 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.