I have somewhat expensive task that needs to be executed a few times by my users. The task uses the ImageTracer library. This task starts off taking about 1 second, but usually after executing a few times (2-10) the task suddenly takes 20+ seconds, even though none of the input arguments are different. Sometimes I never hit this increase, and sometimes it takes much longer to hit.
Other libraries I am using:
Vue.js
Fabric.js
My first guess was that this is some sort of memory issue, so I went to chrome dev tools and captured the heap size. You can download the profile here and here is a screenshot:
You can clearly see that the last 2 task executions took significantly longer than the first couple. I am not very experienced with js and the chrome dev tools, but that doesn't seem like a memory leak to me. The heap size is not significantly larger at the end than at the beginning (both around 8mb). Please correct me if I am wrong and this does indicate a memory leak.
However those memory spikes seem like they might be an issue (or maybe a symptom of some other issue). Zooming in you can see an immediate jump from 15mb to 80mb and then back down to 15mb only 20ms later. Strangly the jump seems to coincide with a Major GC.
I am not sure if this is a problem and if it is how to further debug it.
I tried whittling the code down to a small self contained reproducible example, but as I got the code smaller and smaller the error became more and more rare to trigger, eventually disappearing. To me this also indicated I am dealing with some sort of memory issue.
I have made a somewhat simplified version that does show my issue however.
For me this problem is only reproducible in Chrome (also tested in Safari and Firefox). I am using a 2018 MacBook Pro with 16GB of memory and running Catalina.
My Questions:
Can anyone see an obvious issue in the profile posted above?
Is this most likely a memory bug and if so what are the next steps to continue debugging?
Are there any workarounds that would enable me to essentially reload or reset the offending js library (since the first couple of task executions always seem to go smoothly.
Update 2018-03-01:
This issue has apparently been fixed in version 66. Tested a number of pages in Android Chrome Dev and Canary, no crashes observed even during long and/or heavy runs. I never did find a workaround, however 66 should be hitting Chrome Beta soon, and not too long after Stable so normal users should be able to run them again on Android in the regular version of Chrome within a few(ish) weeks. Incidentally, this is the same update that Chrome will fully discontinue trust in Symantec-CA-based HTTPS/SSL certs. I have noticed it seems slightly janky in comparison to before, but will have to test as this could be merely subjective on my part, or due to changes in my code looking for workarounds. Further info can be found in the Chromium Bug report linked to below.
** Note: If you've followed this post... I have to admit I thought I had a workaround by rounding values to only two decimals out. However, I later realized this was causing a side-effect (because of an optimization I had made) of scale3d-ing some elements to 0,0,0, essentially causing them not to be rendered, and thus not triggering the problem for a long time. When I temporarily removed scaling, said elements rendered again, and the bug was triggered. Deep andhumble appologies, but-- problem not solved. So, I have removed my answer. Here are some things I have tried, none of which were successful:
Rounding transform decimal values to x.xx, two digits out.
Rounding transform values to straight integers.
Using setInterval instead of RAF to see if that was a factor (ugh!).
Using a style tag and .innerHTML to set dynamic transforms via css instead of the DOM (this was surprisingly efficient, but still triggered a crash just the same.
I've tried narrowing it down to particular transform parameters, numerical patterns, element nesting depths, just about anything I can think of to get around triggering a crash, and it looks like there is only one pattern: every time you do a transform there is a chance of a crash. It's a seemingly tiny probability, but doing scripted animations, even if you optimize to prevent repeats of identical transforms, makes the crash inevitable. I can make it take longer, but I can't prevent it.
Now, I've seen similar reports all over the web regarding recent problems with CSS in Chrome since November, when version 62 update was pushed on the stable channel. This last test, using a dynamically generates, embedded style-sheet to update the transforms was especially dis-heartening. There doesn't seem to be a way around it except to wait for version 67 when chromium.org says the fix should come out. That is months away for the typical Android-user.
This problem is not relegated to scripted animations either. I've seen similar issues reported with CSS animations and transitions as well.
I've gone to the extent of trying a number of my animation engines from the past, all of which work beautifully on version 61 down to when RAF was available. I've even written new, simple test engines, just for this. I've tried a number of other developers engines. Still crashes.
At this point, I think the only thing that can be done is to wait for the fix, and possibly get enough attention from enough people to hope they will up the priority.
They said in the ticket it's a problem with a code-optimization. I would really like to see them revert that portion back in version 65 before it hits the stable channel, so the average user will not see this problem soon. There's still time to generate another build and get it out before then.
Anyone who would like to see this happen, please go to the link below and put your two cents in on the ticket at chromium.org.
PREVIOUS UPDATE: This issue has now been tested and confirmed at chromium.org as a bug in the GPU rasterization code, affecting up to version 66 of Chrome for Android, and appearing after build 62.0.3197.0 (the last build unaffected). Their engineers are now working to fix it.
I am leaving this open for anyone who has run into this issue, so they don't think it's a problem with their code, and in case anyone happens to read it that can either contribute to the fix or offer a reasonable workaround until a patched build is released. If anyone does find a workaround, please provide it as an answer here.
For those interested, the link to the ticket is below. Here is an excerpt from the bug report:
Tested the issue in Android and able to reproduce the issue.
Steps Followed:
1. Launched the Chrome Browser.
2. Navigate to the URL: https://keithclark.co.uk/labs/css-fps/
3. Tap on any of the tab and try to access the game
4. Observed that Chrome gets hanged.
Chrome versions tested:
64.0.3282.116 Stable/Beta, 65.0.3325.16 (dev) 66.0.3328.0(Canary)
OS: Android 8.1.0
Android Devices: Pixel
Using the per-revision bisect providing the bisect results, Good Build
- 62.0.3197.0 (497604) Bad Build - 62.0.3198.0 (497674)
You are looking for a change made after 497614(GOOD), but before
497615(BAD).
Previously:
Not quite sure if this is a Javascript, CSS, or Android problem-- but here goes...
Basic Question: What do I need to do to keep my pages with scripted RAF 3D transforms from locking up Chrome vs. 62 and above on Android? Is anyone else having this problem?
**Note: This problem may actually be a Chromium issue. I have opened a bug report with Chromium Project. Those interested can view the ticket here: https://bugs.chromium.org/p/chromium/issues/detail?id=805525
I am leaving this open for now so they can view the full description, and in case it turns out I can fix my own pages with a change to my code. But please, read on... ;)
Background:
My pages work great on 61 and below. I manually updated Chrome on my Samsung Note 3 to version 63 stable recently, and found every page (not just mine) with complex, nested 3D transforms running on a requestAnimationFrame loop would lock up the browser. A perfect example is a page from Keith Clark, who has a CSS/HTML/Javascript proof-of-concept demo of a First-Person Shooter. Now, the mobile version worked great on my phone before. After the update, it locks up. My pages work really good, even on weak devices, till this update.
I've narrowed it down a bit. If I clear cache, and uninstall updates, the stock Chrome (41) runs these things great. Install updates to 63, 62, 64(beta), same problem. I can't remember if I tested 60 or 61, but update to version 59 and we're still golden. Firefox is fine. Opera is well, Opera. Same updates on desktop run great.
What I'm not totally sure of is if it's a problem with my phone. No other problems, ever. I know it's a little old, but it still blows most mobile devices off the shelf. Android version 5, Lollipop. Rooted. If any of that matters. Malware scans have always produced 0 with any AV/M app I've tried. I'm very careful.
Anyway, if anyone else has had this problem, or knows of it...
What do I need to change in my code to make it compatible with current Chrome on Android? Is this a problem I need to solve with code? I've looked everywhere but can't seem to find info specifically on it. All I can say is it's breaking my animations. I can't even use dev tools to figure it out, as running a perf check from my computer crashes my phone so bad Chrome dies and loses the connection and any performance data gained, taking my phones wallpaper along with it!
I'm not picking up any errors from my script-- it's fairly basic. I stripped it down to bare bones because I thought I had a runtime error, but nothing. Is there a change with the way Chrome for Android interprets the CSS or does the layering or something?
Sincere apologies if this ends up being off-topic, as I'm not totally sure if this a coding issue, or just a problem with my phone in particular. If it's a coding issue, that's what I need to know-- and how to fix it.
http://bit.ly/Z7YPj7
It works fine on the desktop everywhere, and also on Android. But on the iPhone Simulator, the culprit appears to be in the file: js/the-anim36.js (which queues a whole bunch of Raphael SVG animations).
I'm monkeying around with Safari 6's "Develop" menu, which can now log info from the XCodes's iOS Simulator, which i downloaded and fired up. But I'm getting absolutely nothing in the javascript console, and a hard crash in the simulator each and every time I open the html file. I have to "Reset Content and Settings" each time I try to open the file. I'm frankly lost here, admittedly a novice at debugging in general (and also probably spoiled by Chrome.) Any pointers on what's possibly going on here would be very appreciated.
You can run out of memory really fast on iOS. Run it through the Chrome profiler and see what you're memory usage looks like. I bet it's using > 10mb of ram. In which case you're probably toast!
Check out this informative article, that claims after about 6mb of ram, you will crash mobile safari:
http://cubiq.org/testing-memory-usage-on-mobile-safari
I observe that when I open that page my laptop fan run on high. The thing is consuming a lot of CPU (and likely a lot of RAM) and may simply be exceeding the allowable resource limits on iOS. If not running out of RAM it could be causing the foreground process to run too long, triggering the logic that cancels "looping" apps.
I've lately been running into odd issues, which I'm starting to think are related to resource starvation in the browser.
In FF:
I'd been testing one of our web apps and suddenly things that should disappear after a couple seconds stopped disappearing. I tracked back to setTimeout just flat out refusing to work. After reloading the browser it was all clear, no issues.
In IE:
I regularly see issues where IE will refuse to do transparency all the sudden, simply reloading the page clears this up.
In both:
Though I can't say its related for sure, I see unexplainable behavior, things along the lines of variables not being available (undefined) when they should be.
Both browsers also show a steady increase in memory usage over time (memory leaks).
The javascript in the web app is heavy and it is a single load page (making those memory issues mentioned all the more painful). There are lots of in-efficiency, and various things that make one say "why would you do that?".
Has anyone encountered such things? Can you point out general resources that will help identify and resolve these issues?
You could try running your application against the Chrome Profiler http://code.google.com/chrome/devtools/docs/overview.html. You can profile the CPU and get snapshots of the browser heap, that should help locate any rogue stuff.
If your application is designed to work with the Internet Explorer: The Developer Toolbar also has a profiler.
I build this
http://ipl.janstudt.de/
website which is supposed to run on the iPad (it does) and in Google Chrome. In Chrome (on Win 7 64bit), after a seemingly random time of a few minutes, the browser freezes. Also, sometimes when I click the "Reload Page" button in Chrome while on this site, the Browser also freezes. In both cases, the Browser recovers after 10-20 seconds.
How do I get to the bottom of this? There are no Javascript Errors. The memory footprint is very modest and does not increase over time (according to the heap snapshots). There are no plugins involved.
I really doubt it is your script; rather, I think it is Chrome doing something silly. I would test it on other similar systems to see if you can reproduce it. I've had it running on mine for about 5 minutes with no issues (Win7, 64bit, Chrome 5.0.375.127).
You could try to keep the profiler running and catch the freeze-up, but I think that would just be a waste of time.
Landed here while dealing with similar issue. Got a solution by changing hardware acceleration settings
FYI:
https://productforums.google.com/d/msg/chrome/daV0DhOXKVI/oBPZ6pUtBgAJ