Memory issue with autoplay + loop

[dportalesr]

Some of our users were reporting that our site was crashing in their Chrome browsers after some minutes on the homepage. I noticed memory consumption in that page went above 1GB before the tab crashed.

We found the cause to be the asciinema-player. It was configured with autoplay and loop options enabled. Disabling the loop option seems to be a workaround, but maybe you'll want to look for any memory leak issue in your code.

Chrome 48.0.2564.109 (64-bit)
OSX 10.11.3

[ku1ik]

Thanks for reporting. I'll investigate.

[ku1ik]

@daetherius You can re-enable loop and it should be fine now.

[jrheard]

@sickill - sorry to bug you, just curious - how'd you go about diagnosing+debugging this issue? i'm a rookie cljs dev and wouldn't know where to start if one of my apps had an issue like this. is there a particular portion of the chrome developer tools that was useful for you here, or some sort of blog post where you learned about how to debug js memory issues, etc? thanks a ton!

[dportalesr]

@sickill Thank you very much!

[ku1ik]

@jrheard sure! So, I opened Chrome's "task manager", loaded asciicast page with loop on and observed the growing memory for this tab. Then I stopped playback and noticed that memory is no longer growing but the CPU usage is ~60% for this tab. So I went to dev tools, and created CPU usage profile (just went to Profiles and hit "Start" there). It showed me a list of functions that were observed to be running by profiler. I chose the one with the highest % next to it. It was from core.async so I kept expanding the call tree and at about 4th or 5th level, after getting through all core.async/clojure.core calls I got to a function from my namespace. The line number pointed me to a line where I start (go ...) block. Then I just analyzed this function and few others that call it and realized that I used core.async' sliding-buffer (I had a reason for that), which is non-blocking buffer, meaning that it's not enough to stop reading from this channel to stop (block) the producer (which in my case was still running even after the playback was stopped).

[jrheard]

Thanks a ton, that's super helpful information to have for when an issue like this inevitably bites me in my own projects :)