I'm trying to analyze a memory leak in our web application. So, I am trying to follow the steps mentioned in the link https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md to generate heap dump of chrome and analyze it.
I'm stuck at step 4 of 'How to obtain a heap dump (M66+, Linux, macOS, Windows)' section where I have to symbolize the trace/dump. I'm trying out the 'Windows only' option of Step 4. Does anybody know what does the statement 'For subsequent commands, add the flag --addr2line-executable=' mean?
Related
I am investigating a JS memory leak issue using Chrome DevTools. Using heap snapshots and doing comparison, I was able to root cause the component responsible for leaking the memory.
Problem I am seeing is that after the fix, even if Chrome DevTools shows no leak, Windows Task Manager shows increase in memory with usage.
Below are the heap snapshots of before and after fix.
Before fix:
After fix:
Am I missing anything here? Is Chrome DevTools somehow showing wrong result?
I read a similar thread here. But it isn't of much help.
Google's documentation on how to do this is now out of date: https://developers.google.com/web/tools/chrome-devtools/memory-problems/allocation-profiler
The dev tools UI has changed since this was written (I'm using v66), and I can't figure out how to get to a heap allocation bar graph which looks like this:
Can anyone walk me through this? I've gone to Settings and checked Record heap allocation stack traces which I believe is one step that is required to do this. In the performance tab I've checked the memory box and have recorded some actions, but once that's done I get more of a line graph for heap, rather than a bar graph:
Halp?
Memory profilers are moved to Memory panel. The one you're looking for is called "Allocation instrumentation on timeline".
I'm using QEMU to test some software for a personal project and I would like to know whenever the program is writing to memory. The best solution I have come up with is to manually add print statements in the file responsible for writing to memory. Which this would require remaking the object for the file and building QEMU, if I'm correct. But I came across QMP which uses JSON commands to manipulate QEMU, which has an entire list of commands, found here: https://raw.githubusercontent.com/Xilinx/qemu/master/qmp-commands.hx.
But after looking at that I didn't really see anything that would do what I want. I am sort of a new programmer and am not that advanced. And was wondering if anyone had some idea how to go about this a better way.
Recently (9 jun 2016) there were added powerful tracing features to mainline QEMU.
Please see qemu/docs/tracing.txt file as manual.
There are a lot of events that could be traced, see
qemu/trace_events file for list of them.
As i can understand the code, the "guest_mem_before" event is that you need to view guest memory writes.
Details:
There are tracing hooks placed at following functions:
qemu/tcg/tcg-op.c: tcg_gen_qemu_st * All guest stores instructions tcg-generation
qemu/include/exec/cpu_ldst_template.h all non-tcg memory access (fetch/translation time, helpers, devices)
There historically hasn't been any support in QEMU for tracing all guest memory accesses, because there isn't any one place in QEMU where you could easily add print statements to trace them. This is because more guest memory accesses go through the "fast path", where we directly generate native host instructions which look up the host RAM address in a data structure (QEMU's TLB) and perform the load or store. It's only if this fast path doesn't find a hit in the TLB that we fall back to a slow path that's written in C.
The recent trace-events event 'tcg guest_mem_before' can be used to trace virtual memory accesses, but note that it won't tell you:
whether the access succeeded or faulted
what the data being loaded or stored was
the physical address that's accessed
You'll also need to rebuild QEMU to enable it (unlike most trace events which are compiled into QEMU by default and can be enabled at runtime.)
How can I record memory leaks in Google Chrome similar to what is being performed in the link bewow?
https://github.com/driftyco/ionic/issues/1096
I have an Ionic app that runs embedded video, after clicking back and forth for over 10 pages during intense clicking it crashes. The pages viewed are embedded mp4s, I suspect there is some memory leakage as listed in the link above? Just need to find a way to test it
Following the post below from Ant, here is the memory log from Google Canary
http://i.imgur.com/QrwTNwe.jpg. Do the nodes and listeners look unusual?
Get chrome canary then open developer tools and click on profiles.
Using the tools there you can take heap snapshots and compare memory allocations between snapshots to see what is staying in memory or you can record heap allocations which records memory allocation in real time on a timeline so you can dig in and find where memory is not being released.
https://developer.chrome.com/devtools/docs/javascript-memory-profiling
There are some very good guides on the technicalities of doing the above if you google how to find memory leaks.
I am building an application with a simple search panel with few search attributes and a result panel. In the result panel, I am rendering the data in a tabular form using Slickgrid.
After few searches (AJAX call to server), the page gets so much loaded and it eventually crashes after sometime. I have checked the DOM count and the JavaScript heap usage for possible memory leaks. I couldn't find anything wrong there. However, when I ran the experimental native memory profiler, I see that the "JavaScript external resource" section uses 600+ MB memory. On running the garbage collector, it is getting down to few MBs. I have couple of questions here:
What contributes to the "JavaScript external resource" section? I thought it corresponds to the JSON data / JavaScript sources which gets transferred from the server. FYI, the gzipped JSON response from the server is ~1MB.
Why is Chrome not releasing the memory pro-actively instead of crashing the page? Again, when I manually run the garbage collector, it is releasing the memory used by "JavaScript external resources".
How do I fix the original problem?
JS Heap Profiler makes a snapshot of the objects in the javascript but javascript code may use native memory with help of "Int8Array", "Uint8Array", "Uint8ClampedArray", "Int16Array", "Uint16Array", "Int32Array", "Uint32Array", "Float32Array" and "Float64Array".
So when you take a snapshot it will have only small wrappers that point to native memory blocks.
Unfortunately heap snapshot does not provide data about the native memory that was used for these kind of objects.
Native heap snapshot is able to count that memory and now we know that the page uses native memory via an array or via an external string.
I'd like to know how did you check that the page has no memory leaks? Did you use three snapshot technique or just checked particular objects?
Tool to track down JavaScript memory leak