samccone / drool

Automated memory leak detection and analysis

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Dealing with chrome's undo stack

samccone opened this issue · comments

tl;dr - Typing into an input results in a node count increase that is non-trivial to track down, and presents itself as a node leak in your app.


What

In Chrome, whenever you type into an input, chrome stores a (node) entry in the undo stack.. Which allows a user to then press command z and undo the given action.

Ok seems reasonable, so why is this an issue for people that are interested in doing memory profiling?

If we take a look at UndoStack.cpp

image

image

We can see that we are storing up to 1000 records in the undo stack, which means that if you had a test that involved typing into an input multiple times you would think that there is a node leak in your app. 😿

image

A keen observer might wonder though if they were to press the force GC button in devtools, shouldn't all nodes that can be garbage collected be cleaned up? That is a valid thought, and normally would be true, however because we are holding onto these references in the undo stack, a force garbage collection will never collect these items until they are evicted from the stack... But there is no way to force this eviction to happen 💀


Potential Solution

It would be possible to write a setup step that would create an input and then type into it 1000+ times thus filling the buffer. After the buffer was full the diff between two snapshots would then not be impacted by the undo buffer since it would be at a constant 1000 nodes regardless of the tests typing into new inputs. 💥

Chrome Side Solutions

If chrome was to expose in the counts trace the number of elements inside of the undo buffer it would be possible to calculate the diff without having to "hack" this solution together. This patch however would be somewhat invasive to the chrome core and may not be worth it.. however it is an interesting metric that could be valuable to a subset of users. cc @paulirish

Another solution would be to clear the undo stack when the user pressed the GC button or manually invoked the gc(), this seems like it would be a pretty simple solution that would resolve these concerns.


xref