-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include debug_helper
to llnode
#571
Comments
I still use llnode constantly, even in its relatively broken state. I would like to find time to contribute to it, but it's been difficult being a one person team currently. 😐 |
Thanks for the input! I'd love to hear a little about why you use llnode Also, which features do you tend to use? I am curious if there is a |
I'd like to help too. My concern is more regarding my knowledge in the field than the bandwidth ^^ But maybe could we write down a list of things that could address the broken state of the project and see how could we improve it incrementally? Maybe with small/scoped tasks, it could be easier to tackle them? (even for me, then I could help) Also, note that during our last meeting we mention the idea to find a new principal maintainer for the project. |
I'm not sure about the limitations or how often it's used but there is $ lldb --one-line "command script import deps/v8/tools/lldb_commands.py" -- node
> run
...
> jst # javascript stack trace
...
|
My use-case is mainly the live debugging aspect. Setting breakpoints, running, getting the backtrace where it breaks, inspecting objects in the frame to see if they are what they are supposed to be, etc. Heapdump stuff alone is insufficient for most of my uses. 😅 |
I think at every point the incremental maintenance burden feels pretty
My feeling is it will be hard to find someone willing to maintain the project. Here are all the commands
I think the maintenance difficulty is that all of these commands depend If it was built on top of
nodejs/node#32402 has some color. I don't think exposing V8 internal |
Whatever we do, it should probably be contributed upstream to V8 to avoid it getting out of sync. |
Yeah, whatever we do, it should probably be maintained in V8 codebase so it stays in-sync. Probably just make it directly usable in d8 and have Node.js just inherit the functionality that way. Might not be able to have Node.js-specific stuff though. 🤔 |
Neat! On my side, I cloned the project and saw that some tests were failing. Maybe a good way to become more familiar with the codebase. |
As an FYI as possibly this did not make it back to the Diagnostics WG. @No9 has volunteered to help maintain llnode and was added as a maintainer. He will only have so many cycles but at least we have a maintainer who can review/land PRs if those who are interested send them in. |
Thanks @mhdawson for the ping.
|
Can we add it to the support list again, then? https://github.com/nodejs/node/blob/main/doc/contributing/diagnostic-tooling-support-tiers.md |
As someone that hasn't contributed yet but would be interested in helping, I'd be down for a call to learn what the current state is and to understand what I can do to help. 😊 |
+1 |
Maybe we can have it in one of our Diagnostics meetings |
I commented on nodejs/llnode#399 with some more specific info on why I still think that incrementally maintaining llnode is hard -- you can |
@RafaelGSS Good suggestion on taking a slot in diagnostics meeting - I'll look out for the next session. |
@Qard @tony-go @kvakil HT @RafaelGSS |
We are interested in providing support for this feature. If anybody wants to take the lead o that, feel free to move on. Removing from the agenda. |
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made. |
llnode
was 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
llnode
is 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
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
nowllnode
relies 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
.llnode
works 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
llnode
is 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
GetStackFrame
andGetObjectProperties
functions. 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_helper
does not work with Node'sconfiguration, or that I just didn't work out the build system correctly.
The text was updated successfully, but these errors were encountered: