Repository navigation
v8 findrefstree command #115
Description
Activity
I think we could probably do this but before diving into the technical side what would the output look like?
We need to build a path from an object (through many other objects) to possibly a number of roots. I'm not quite sure how to present that in a terminal window in a way that's usable. I've seen tools for walking the incoming references to an object before but they've generally been in GUIs.The resulting tree can be very deep (if it passes through structures like linked lists) and very wide (if it ever passes through objects with many incoming references). I'm not sure how to make it presentable in a way that's useful.
@hhellyer perhaps we can generate it into a common format that we've been discussing over here? nodejs/post-mortem#13
lldb may not be the best tool to search through the generated tree, but if it's exported in a common format we could write tools to import it into a database and run queries.
Thoughts?
I'm not sure if we could export the heap from a core dump into another format correctly. We currently have no way to get all the heap roots out of a core dump. (I'm fairly sure I've discussed this somewhere else but I can't find the reference.)
Getting the incoming references is something you need as soon as you start doing any kind of heap dump analysis so it would be worth thinking about and discussing on that thread
It might not be something we'd want to put into the dump as it's generated but you could add them via post processing or simply generate a dump in the same format with the references reversed. There might need to be a header flag saying which way the references went or you might use the two dumps as a pair - this all probably needs more thought but that should probably happen over in the discussions of the common format.IMO the best way to meet this requirement would be a GUI front end to the core-dump reader, so you can click on an object and open up a 'reversed' view of the objects that refer to it, with collapsed/expanded views of arrays etc. We are some way from having that. However, I think we could do something in line-mode if we control the amount of output using counts and ".... 200 more like this" type messages, with options to expand fully.
I was playing with some ideas on how to output this. Here is what I've got so far:
For small trees, I believe something like this would work. We could add a
--max-depthflag to limit the output size for larger trees. Also, after #147 lands, we can have this exposed as a JS API, which will make it easier to handle larger trees.Edit: for comparison, this is the retainers list on Chrome DevTools with the same script:
- added 2 commits that reference this issue
on Oct 23, 2018 - added a commit that references this issue
on Feb 11, 2019 - added a commit that references this issue
on Feb 25, 2019 - added 2 commits that reference this issue
on Mar 5, 2019
It'd be really useful to have a
v8 findrefstreecommand for solving memory leaks. This would take a reference to an object, and starting from that node, print out all objects that refer to that object, and its parents, recursively.Generally speaking this would be helpful for debugging memory leaks, as it's usually pretty obvious what objects are leaking, but not the root object(s) that's holding on to the leaking objects. Currently you'd have to run
v8 findrefs -rover and over an object and its parent until you reached the root, which is slow and very tedious.Having a command that could recursively print out the tree of objects that refer to a specific object would simplify the debugging process for memory leaks.