You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
llnode was a great tool to have. Unfortunately it is currently
unmaintained and so it has been removed from the diagnostic tooling
list, see nodejs/node#43289.
Why llnode is good
V8 heapdumps are slow. It traverses every live object and
constructs the graph. In my experiences, heapdumps are often much
slower than a coredump, making them unusable for live production
debugging.
V8 heapdumps do not provide visibility into external memory usage.
To some extent, diagnostic report has subsumed the need for llnode
postmortem debugging. However, the ability to inspect all active
objects and state is still more powerful than what diagnostic report can
feasibly provide.
Problems with llnode now
llnode relies heavily on V8 internals, which means that it breaks
every once in a while. See Not showing details of JS frames on node v16.14.0 llnode#399 for the most recent
example. Resolving these issues is hairy; it essentially requires
somebody who understands the V8 change and can replicate the change for llnode.
llnode works by walking every byte in the process space and looking
for things which look like V8 objects. In addition to often producing
false positives ("ghost objects"), this is extremely slow for
larger heap dumps.
Alternative proposal
I do not know if llnode is actually something that needs to be
maintained. There seems to be a decent amount of community interest in
it based on the Github repo, but perhaps those people would be better
served by diagnostic report anyway. Perhaps somebody should try to
figure out why people are still using llnode?
If an llnode-alternative is desirable, I think it would make the most
sense to build it on top of V8's debug_helper library, which is what v8windbg uses. The debug module includes GetStackFrame and GetObjectProperties functions. Presumably V8 would be receptive to
patches to implement other functionality.
I tried to write a gdb extension which used debug_helper.
Unfortunately it did not seem to work that well and gave some wrong
results; it's possible that debug_helper does not work with Node's
configuration, or that I just didn't work out the build system correctly.
llnodewas a great tool to have. Unfortunately it is currentlyunmaintained and so it has been removed from the diagnostic tooling
list, see nodejs/node#43289.
Why
llnodeis goodV8 heapdumps are slow. It traverses every live object and
constructs the graph. In my experiences, heapdumps are often much
slower than a coredump, making them unusable for live production
debugging.
V8 heapdumps do not provide visibility into external memory usage.
To some extent, diagnostic report has subsumed the need for
llnodepostmortem debugging. However, the ability to inspect all active
objects and state is still more powerful than what diagnostic report can
feasibly provide.
Problems with
llnodenowllnoderelies heavily on V8 internals, which means that it breaksevery once in a while. See Not showing details of JS frames on node v16.14.0 llnode#399 for the most recent
example. Resolving these issues is hairy; it essentially requires
somebody who understands the V8 change and can replicate the change for
llnode.llnodeworks by walking every byte in the process space and lookingfor things which look like V8 objects. In addition to often producing
false positives ("ghost objects"), this is extremely slow for
larger heap dumps.
Alternative proposal
I do not know if
llnodeis actually something that needs to bemaintained. There seems to be a decent amount of community interest in
it based on the Github repo, but perhaps those people would be better
served by diagnostic report anyway. Perhaps somebody should try to
figure out why people are still using llnode?
If an llnode-alternative is desirable, I think it would make the most
sense to build it on top of V8's debug_helper library, which is what
v8windbg uses. The debug module includes
GetStackFrameandGetObjectPropertiesfunctions. Presumably V8 would be receptive topatches to implement other functionality.
I tried to write a gdb extension which used
debug_helper.Unfortunately it did not seem to work that well and gave some wrong
results; it's possible that
debug_helperdoes not work with Node'sconfiguration, or that I just didn't work out the build system correctly.