-
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
Discuss: State of llnode #202
Comments
I wrote this a few months back, but it's outside of any official channels.
I want to agree with you here, but it's extremely impractical without some type of commitment or collaboration with V8. (Also, what about ChakraCore?)
An unscientific Twitter poll I ran a while back said that most people thought postmortem debugging was too hard, didn't think it was worth it, or didn't know how. I can quote at least one TSC member as saying that postmortem debugging should just be a thing of the past. As promises are used more and more, without a great solution for them, I think fewer people will care. Without many users, there will be even fewer people willing to maintain a tool with such a steep learning curve (in some cases you need to reverse engineer what V8 is doing). I'm not trying to be negative here - I'm a big fan of llnode, but those are the challenges that I see. |
@cjihrig I agree with everything you said.
I think we'll be able to improve llnode's usability once the JS API lands. For example, we could have a GUI or our own REPL.
Have they suggested any alternatives? V8 Snapshots are too expensive to be used in production, and they don't provide all the information we can gather with core dumps (the complete call stack, inspecting JS contexts and scripts, etc.).
Agreed, but to move forward on how to handle promises we need more people contributing (which is hard).
For some time now I wanted to try to use V8's API (or even N-API) to write something similar to llnode, which wouldn't require so many hacks and wouldn't rely on postmortem metadata to inspect a core dump, but I didn't had the time to work on it yet. |
I have to agree with @cjihrig on this for now, if llnode being in tier 1 means breakage of llnode would block V8 updates in core.
On one hand I am optimistic about this, on the other hand based on a GUI prototype (cannot release it because I worked on it in my last job) that I've developed before and observations from using llnode with a lot of in-production core dumps (frequent crashes caused by lldb itself, cannot deal with a lot of core dumps while gdb works fine, etc.), I don't think the tool is ready, especially after I've seen this post from a year ago in the lldb mailing list. For example, sometimes I have to use this hack in order to load core dumps with lldb, but it does not always work because there are deeper issues with how lldb just crash when it encounter things that it does not support or just doesn't try hard enough. It's nice to have this tool usable when I need to debug C++ and JavaScript together and it's kind of painful when I couldn't, but with the support of lldb itself I think that's where we will be for some time. The JS API does not solve the issue of lldb and a crash of the background process of a GUI tool is very confusing even if I know it's not unfixable. You just get lazy when you think about the llvm development process (svn, mailing list, giant repo, .etc). |
I also agree w/ Colin here. Not sure what the solution is - any debugger extension working over a core dump is going to require detailed understanding of the host + VM internals, and those internals will change. I also agree that the right approach here is to push all knowledge of VM internals down onto the VM, and land on a stable API that debugger extensions can take a dep on. Perhaps this API becomes part of n-api. Need to get the VMs to sign up here to support this. Not sure what V8 already has in place here. Chakra has a windbg extension that understands externals, but unless someone volunteers, I don't see that being ported to any other platforms. Also, I agree w/ above that this is a scenario/tool w/ narrow appeal. For most JS devs, they only care about the JS stack + JS heap. The question is, is a JS stack + heap sufficient to debug a core-dump in a meaningful way? Or, is it the common case that by the time you have a core dump, the failure is pretty deep & the JS stack + heap is useless? That said, in terms of design, it would be nice if there was a system like this:
|
Having used llnode to debug many in-production core dumps, my answer is yes. If someone's app is stuck in an infinite loop (which is not that uncommon I am afraid, especially in buggy loggers), it's possible to use gcore to trigger a core dump and use that to see the call stack. Sometimes it helps with OOM if the objects causing it is obvious from the object count/total size (you'll be able to trace the reference with llnode), or if it happens that the app is running code that cause the OOM, like some code that tries to join a huge array then you'll be able to see where that array is coming from. Sometimes it helps with segfaults if you need the JS stack for reproduction. But the core dump is obviously not a silver bullet, also lldb itself does not work as well as gdb with a lot of core dumps.
It's very rare that the JS stack or heap is completely useless. It's just hard to know where to look if you are not familiar with the code base and there are a lot of |
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. |
This spun into other issues so I believe it can be closed. Feel free to reopen if more discussion is needed. |
Follow up from the Diagnostics Session in the Collaborators Summit:
llnode
is a project under the Node.js org., and since it is a diagnostic tool it should be of our interest as a Working Group. Right now the project is fairly stable but has some issues:llnode
is mostly known and used by Core collaborators and a handful of enterprises with large deployments. There's little content aboutllnode
, and I couldn't find any content aboutllnode
on nodejs.org, Node.js Medium or Node.js Youtube Channelllnode
not working for the latest version of Node.js.I'm bringing this up as a discussion related to #157.
llnode
is a tool worth being 1st tier supported based on its importance for Core and Native Module developers as well as enterprise, but since it is a less known feature with a low bus factor its too risky today to havellnode
as a potential blocker for releases.Would love to discuss some ideas on how to improve the current scenario of the project.
The text was updated successfully, but these errors were encountered: