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
First, thank you so much for providing and maintaining wtfnode! It has been indispensible in so many 'wtf' situations for me and my team.
Right now my typical workflow when I encounter a mystrious hangs-on-terminate issue is to run things with wtfnode and then instrument the functions that show up in the dump with something print stack traces because almost always the problem lies a few calls up. Even though in the end this usually gets me there, its clearly not ideal for several reasons:
I have to go and instrument my code
Since at the point where I instrument the code it's not yet known for any given invocation whether it will eventually lead to a 'wtf' situation or not I usually end up with (potentially very very many) printed stack traces from the same number of invocations and then after the fact need to sift through them to find the ones that are causing the issue
Clearly all of this could be much nicer if wtfnode could just include full stack traces for any invocation in the dump.
From having a quick glance at the code it seems that complete stack frames are actually already generated so computational impact should be minimal.
The text was updated successfully, but these errors were encountered:
I was busy typing up a response when I got your PR... sorry about the mess that is the code, I started on a much cleaner rewrite ages ago but wound up getting busy. I think this is a reasonable request, my main concern was whether it would be too noisy to understand. I'll check out the branch and poke at it to make sure things seem good.
First, thank you so much for providing and maintaining wtfnode! It has been indispensible in so many 'wtf' situations for me and my team.
Right now my typical workflow when I encounter a mystrious hangs-on-terminate issue is to run things with wtfnode and then instrument the functions that show up in the dump with something print stack traces because almost always the problem lies a few calls up. Even though in the end this usually gets me there, its clearly not ideal for several reasons:
Clearly all of this could be much nicer if wtfnode could just include full stack traces for any invocation in the dump.
From having a quick glance at the code it seems that complete stack frames are actually already generated so computational impact should be minimal.
The text was updated successfully, but these errors were encountered: