My Sencha Touch app (demo is here: http://www.bodbot.com/MobileApp/senchademo/index.html) has been crashing on a relatively regular basis on Android and Windows Phone. I have yet to figure out the root cause of the crash despite a fair amount of investigation, so any help would be awesome. Here's what I have so far:
On Android, when the app crashes, I get a signal 11 sigsegv error. Due to the fact that I am working pretty much exclusively in javascript, my assumption is that the likely cause of this segmentation fault would be some sort of a memory leak, since I'm not writing any code that's pointing at anything in memory.
When I use Chrome's timeline memory analysis and use the app very heavily, the memory usage pattern does seem to clearly indicate a memory leak, especially when compared to similar usage on one of Sencha Touch's demo apps. (screenshots below)
My problem is that I can't track down the (assumed) memory leak. I'm doing everything that I've found about optimizing sencha for memory:
I'm using listener delegates pretty much exclusively
I make sure that most components that aren't currently being viewed are destroyed
I don't go too nuts on the global variables within javascript
It does look like Chrome's "Record Heap Allocations" might be able to reveal something, but given the sheer volume of pieces that it's tracking, I'm having real trouble making any sense of it.
Am I missing a method for optimizing memory in Sencha Touch? Is there a more effective way than Chrome's Record Heap Allocations for tracking down Sencha Touch app memory leaks?
Screenshots:
Related
I am developing a voxel engine in Javascript using Threejs, and I've run into some memory usage problems. The intended environment is within an Electron application, which means I can launch the program with flags (--expose-gc) that enable manual garbage collection with gc().
I noticed that when running the gc() function, much less memory was freed compared to when I clicked the "collect garbage" button in the Memory section of Chrome's developer tools. For example, if the program initially used 2000 MB of memory, after gc() it would free up to 300 MB, but after clicking the aforementioned button, it would free up to 600 MB more, making it about half of what it originally was.
After some digging, I also found out about the --gc-global flag. This would've been perfect, since it behaved in the same way as a manual gc did, but it ran multiple times per second, making my program extremely laggy. I tried controlling the gc rate with --gc-interval, but it didn't affect it at all.
I also found this answer that talked about ProfilerAgent.collectGarbage();, but it always threw a reference error. Additionally, the flag it provided (--debug-devtools-frontend) wasn't recognised by Chrome. That, and the fact that I could find very little info on it outside of the answer, lead me to believe that it's an obsolete feature.
I also profiled the memory usage from the developer tools, and surprisingly, it was much lower compared to the value that Task Manager showed me: it seemed to be unaffected by the leaking memory. This has made it nearly impossible to determine where the memory could be leaking from.
I should also make it clear that while Chrome does garbage-collect on its own, it's far too infrequent, and it rarely does a full gc, meaning that memory usage is about twice of what it could be.
In summary, is there a way to trigger a full garbage collection from either Chrome or nodejs/Electron? Obviously, I'm not concerned about cross-browser support, so any advice would be appreciated.
It turns out that self.gc only collects garbage in the thread/worker it was called from. Running the function in all of my workers freed as much memory as the developer tools garbage collector did.
This happens over a period of 90ish seconds. I'm trying to isolate the cause and I can't even begin to figure out where to start, and i'm at the point now where I'm questioning whether this is even a problem- this seems like Chrome is just good at handling performance, rather than we're doing something right. I'm trying to decrease our JS Heap size in general but I don't know even where to start.
In summary:
Does this look like a memory leak or performance problem?
I've read and watched a bunch of videos about FINDING memory leaks but have yet to find a good example of how to isolate and solve them. Any resources-- preferably google team ones-- would be super helpful
Without knowing anything about your application it is hard to tell, but in general do 100 MB of heap space used not particularly have to be a memory leak. Where the spike is going down is just the garbage collection of the Javascript Engine hitting and freeing all not longer used memory. We have a simple desktop application here in development that already uses 75 MB of heap space when it is just idling without doing any rerendering to hold all the states. For your comparison.
You can also check for sources like
https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/
and see if you do things that can cause memory leaks.
Check also:
Finding JavaScript memory leaks with Chrome
Stress testing my Foxx App eventually crashes ArangoDB with a SIGSEGV. Looking at the core file it seems to be related to V8 running out of memory. I'd like to do memory profiling on the heap to help track down potential leaks. Since the V8 engine is an integral part of arangod, how do I access and use the V8 profiler? The node modules that help with this all have C++ modules so they won't run right under Foxx.
Unfortunately, the V8 engine and its garbage collection has some glitches regarding the memory management.
In some cases, it runs in tight loops to squeeze a bit more memory out of the system, sometimes it instantly terminates the process instead of giving its host process a chance to cope with the situation.
This is a problem with which all V8 based solution have to fight - Node.JS too. The V8 team is working on this, and with every version they make progress.
But the end of the road isn't reached yet by now.
Regarding debugging interface which would most probably also provide the memory profiling, we are well aware of that its currently missing and tracking progress on this via the github issue #1538. As resources become available for this topic, we will start working on it.
You probably can use flamgegraphs in some way right now with the aid of the linux kernel, but it seems to be problematic to write the names of the JIT compiled functions required to make this more usefull.
I've tried so many profilers for node I've lost count. I've never seen a profiler that gives you this:
This image shows second-by-second usage of CPU (top and center) and memory (bottom). I can click on a single "frame" (a dividend of a second) to see exactly which functions executed on that frame and what memory was allocated and deallocated (GC'd). This is Adobe Scout for Flash/AS3.
I need to find a ghost (a memory leak :), and I've successfully used the above interface hundreds of times to eliminate unwanted allocations and debug why memory doesn't get freed when it should.
How do I find which part of my app is allocating memory on a visual timeline? I need a timeline to see specifically which part of my app is allocating memory and why. Right now everything happens so fast I can't use the "objects currently in memory" panel to do anything useful. And comparing "heap snapshots" is harder than using a timeline. Web-based or app is fine. I use Windows 7.
I use pm2 as a process manager and they have a dashboard service keymetrics. You may have a look to see if match your need. :)
I just finished writing tests for JavaScript application and I was using Jasmine for the first time. Everything works fine, but I still need to test if application has some memory leaks within. Is it even possible to programmatically check it within my specs? Maybe there is some additional library for this?
Chrome has a non-standard extension of the window.performance API -- (window.performance.memory), where you can measure memory usage.
In order to enable precise memory statistics, you must use this flag: --enable-precise-memory-info
But you also need to force GC to tell whether memory is retained after your test. Because CG doesn't happen instantly.
With Chromium browser, you can run it with a special command flag to expose a method to force GC:
chromium-browser --js-flags='--expose_gc'
This gets you access to the method window.gc().
As I know there is no automatic way to find source of javascript memory leak. Javascript memory leaks is realy nasty thing on which you can waste a lot of time. Recently I was developing very large enterprise web solution as a single page application with almost 1mb of minimized self-written code. Suddenly we realized that our application is leaking hard. I tryied hundreds of technics to find the source of memory leak and the easiest way for me is to use google chrome profiler, take heap snapshot and compare different heap snapshots. Here is more information how to do it :
https://developer.chrome.com/devtools/docs/javascript-memory-profiling
Have a nice week with debugging memory leaks in your app, hope it will take less time that in my case. :)