Re:Two Wishes for Dev Tooling
by kristopolous on Monday July 12, 2021 @09:36AM
(#27810098)
Sometimes you can't attach a debugger at all! I've dealt with plenty of things that will do some strange kind of fork/exec magic and shed all the debug information in the process.
And other things that will only show some small useless snippets of the stack. You pass a bunch of parameters to tell it to show more, but then invariably you find the code is using a custom logger that's cutting the thing off or some part of a library resets all your settings or the forked processes don't inherit everything, it almost never just does what you tell it to, there's something else in there ignoring it.
I wish I could have the opportunity to even get to that problem half the time
I'm not completely sure what you mean here? Debugger not stepping into 3rd party code? The debugger cannot know what you consider to be a maze and what not: are you developing said library? Then you want that code. You want only your code? Then you'll have to tell the debugger which is yours. Example implementation is debugging C or C++ with Visual Studio which has regex-based 'do not step into'.
Get a useful stacktrace that's not just lines of framework wrapper garbage and then an elipses.
Isn't this essentially the same as previous point? You want a relevant stacktrace, i.e. without 'getting lost in a library maze' so you'd need to filter. Don't know if that is implemented somewhere. I personally haven't encountered much need for that though: stacktraces contain the origin of the call (shared library or for Python etc the module path) so glancing over it I skip the 3rd party bits automatically.