8 ms·

Looking for More Debugger

57 points by luu 6y ago

samrat 6y ago
I recently discovered https://github.com/weirdNox/emacs-gdb/ https://github.com/weirdNox/emacs-gdb/ . The installation is a bit unconventional compared to the usual Emacs package installation process, but works pretty well. This recreates the Visual Studio style workflow described in https://twitter.com/pervognsen/status/1098453808651202560 https://twitter.com/pervognsen/status/1098453808651202560 and https://youtu.be/0woxSWjWsb8?t=254 https://youtu.be/0woxSWjWsb8?t=254
flohofwoe 6y ago
Strange that VSCode + debugger frontend extensions (mentioned in the first part) caused such trouble, it's working flawlessly so far for me for mixed Zig/C projects, across Windows, macOS and Linux (Ubuntu 20) The inspection capabilities in the VSCode debugger are very bare bones though, that's true. At least the variable view panel could need some work.
- IAmAtWork 6y ago
  I was so goo at debugging the hardware I underestimated just how difficult will it be to switch to software even when you really good at that language. But set up is important esp for web technologies as they are buggy by default. Interestingly I never had issue with C
dan-robertson 6y ago
I think there are a few sides to this problem: 1. Debuggers are in some sense anti-unix. They only work well when they are thoroughly integrated with the rest of your environment. Trying to have some debugger program like gdb and then talking to it from emacs or a terminal or something will be a big pain. Emacs is also anti-unix but seems to have enough mass that it doesn’t matter so much (or maybe the debugger and emacs fighting for importance is problematics) 2. Getting a debugger to work well is hard. Apart from needing information to work out what bit of code is executing (and passing all that information through weird compilation steps or linking), the debugger needs to understand the memory layout of objects and interpret some subset of the language so that people can enter eg watch expressions. This is hard when the compiler and debugger are quite separate and just agree on the format for possible debug information. Lack of integration hurts again 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? I guess Java too? Lots of people end up debugging with prints and that just isn’t so effective. I think I’ve barely used a debugger for more than trivial websites in the last 10 years. 4. The problem of debugging has become harder: there are now more threads in programs and it is more common for languages to have some kind of async mechanism. If you naively debug that, you’ll see crap stacktraces (a few frames sat atop a scheduler) and execution may move randomly between threads in a pool. I feel like most debuggers can’t cope. (I guess website debuggers do understand async better and there are also new inventions like reversible debugging with rr, but the problem with integrating a debugger with a language or an editor remains.)
- jcelerier 6y ago
  > 1. Debuggers are in some sense anti-unix. it's not a problem when you accept that the unix philosophy is extremely far from the holy grail of software design. "things that do one thing well" certainly has good sides for specific problems, mainly quick'n'dirty linear text processing dataflows, but is atrocious for other problems (anything that need integration and discoverability: art software, web browsers, or revolves more around user interaction than computing something) > 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? if debuggers took less time to start than a full "add print -> recompile -> relaunch app" cycle as is my experience with C++, they would certainly get more use. Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow.
  - DoofusOfDeath 6y ago
    > Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow. I'm really surprised. In my experience it's really rare for either of those debuggers to crash, let alone for both to crash on the same target. A bit of a tangent, but would you mind sharing some details about your compiler / OS / debugger / target-hardware versions?
    - tkinom 6y ago
      Same here. CLI version of gdb has worked extremely reliable for me across multiple projects and architectures (x86, arm, arm64, etc). I have yet to encounter a bug can't be debug with gdb with some test automation + gdb script with conditional breakpoints / hw breakpoints. As long as I can reproduce the issue with test automation, I can debug it with gdb. Most complex bugs are I have to debug was multiple threads (20+) memory leak shows up after days of testing. I don't use GUI gdb. cli + gdb script is the best and most reliable debugging environment. I don't add printf to my code anymore, a new gdb breakpoint script + with proper debug build can replace the printf anywhere and anytime.
jcalabro 6y ago
If you use Windows at all, you should check out RemedyBG[0], it's excellent. But Windows-only. [0] https://remedybg.itch.io/remedybg https://remedybg.itch.io/remedybg
- corysama 6y ago
  They say “early access”. Can anyone speak to its current stability/issues?
GartzenDeHaes 6y ago
I continue to be shocked at the lack of productive development tools on linux. My current c/c++ toolset is: a makefile generator that I wrote after years of wasting time on autotools problems, Anjuta for debugging and rudimentary editing, and Visual Studio 2008 on Windows XP running in VirtualBox for most productive work (it's a cross platform project).
- Cloudef 6y ago
  vim, gcc, gdb, radare2, valgrind, callgrind, helgrind, coreutils, git, make
bjg 6y ago
https://www.gdbgui.com/ https://www.gdbgui.com/ is another good frontend for gdb.
kuter 6y ago
I don't think GDB is too bad. Most people probably don't use watch expressions, conditional breakpoints etc.
- madhadron 6y ago
  > Most people probably don't use watch expressions, conditional breakpoints etc. That's an indictment of the available debugger interfaces that they wouldn't.
- modeless 6y ago
  I use them all the time in Chrome dev tools where there is a nice GUI for them and they actually work properly.
- Cloudef 6y ago
  They become pretty much essential when reversing or debugging a program you dont have source for.
dummy_physicist 6y ago
Some years ago I learned about ProDBG[0] and was pretty excited. It is going through a rewrite, I hope it gets usable soon. [0] https://github.com/emoon/ProDBG https://github.com/emoon/ProDBG
slezyr 6y ago
Qt Creator's debugger is almost perfect for my goals. It's, probably, the most user-friendly. However, I wish I could feed gdb commands directly to it.
- jcelerier 6y ago
  > However, I wish I could feed gdb commands directly to it. you can: while debugging, enable "Debug Log" (in the View menu), and this adds a pane where you can input gdb command. Output is not very pretty though.
saagarjha 6y ago
> It doesn't actually seem to be trying to write "/tmp". It actually doesn't issue any syscalls at all when I press "Debug Main Project" and trigger the message. Perhaps a subprocess is doing this?
dvirsky 6y ago
It's worth mentioning that vim has added debugger integration support as a plugin, but that plugin is available with vim by default, you just need to enable it. It's not perfect but it's usable - you can set breakpoints visually and save/load them, you can step debug inside your code window (gdb is actually running in another vim window and can be controlled directly) and you can see the value of expressions in your code window. This is a nice guide to it: https://www.dannyadam.com/blog/2019/05/debugging-in-vim/ https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
wallstprog 6y ago
The one thing I really miss about Windows is the Visual Studio debugger -- it was frickin' awesome even back w/VS 2005 and I have to believe it's gotten better. On Linux I use ddd, and while it's definitely quirky (in that weird X way), it works just fine. I would guess that many of the poster's problems have to do with Linux's mediocre GUI support in general. I've recently switched to doing development on Ubuntu (vs. RH/CentOS) and all the GUI stuff works much better in that environment, incl. ddd. I haven't tried Eclipse's C/C++ debugger, but its Perl debugger (part of EPIC) is quite nice and works well on both Mac and Linux.
tomgs 6y ago
Disclaimer (and a bit of context): I work for a company that builds a special type of debugger, aimed at debugging live applications in production. As one would expect, we've spent an enormous amount of time thinking about debuggers, how they work from the inside and what they contribute to the general experience of developing software. Debuggers are, for developers well-versed in working with them, priceless tools (see [1] for an example from this very thread). There's so, so much value in walking through a program not only in one's head (as well-put by pg at one time[2]), but by using a tool that enforces a more structured, "formal" process for program exploration. I use it when trying to understand how code I write actually looks like IRL, but also - and maybe more so - for understanding code OTHER PEOPLE wrote with better context than any piece of documentation or simply reading the code would ever give me. But - as the article and some[3] of[4] the[5] comments[6] here point out - it has warts (quick plug - I recently wrote a blog post[7] that details my perspective on remote debuggers and how they can be better). One thing that I didn't see mentioned in this thread or in the article, and is a real PITA, is performance. Debuggers are not built to deal with performance problems - or collection of temporal data, for that matter - at all. Consider how one might go about debugging a real-life performance issue, especially in the context of modern applications - many threads, many hosts, many replicas of the same service, etc. You probably have a tracer - something like Zipkin[8] or Jaeger[9] - that helps you to break apart latency issues in your endpoints. You also probably have a set of instrumented metrics (graphed inside your APM, perhaps) for quick observation when something is not reacting as fast as you expect it to. But sometimes they don't tell the full story - there's just too many possible edge cases. Performance issues can be caused by data structures exploding in size, causing degraded performance and OOMs. They can be caused by one method, in a chain of dozens of different, inter-connected ones, that is especially slow. It can be related to non-optimized SQL queries (maybe hidden behind an ORM). It can be a weird code path - one the developer did not expect, and did not test for - that gets triggered by users with very specific characteristics. Hard. [1] https://news.ycombinator.com/item?id=25960923#unv_25960923:~:text=The%20debugger%20is%20the%20main%20reason,for%20JVM%20or%20dynamic%20language%20stuff https://news.ycombinator.com/item?id=25960923#unv_25960923:~...... [2] http://www.paulgraham.com/head.html http://www.paulgraham.com/head.html [3] https://news.ycombinator.com/item?id=25940064#unv_25957905:~:text=gdb%20and%20lldb%20don't%20work%20great,where%20multiple%20threads%20are%20executing%20concurrently https://news.ycombinator.com/item?id=25940064#unv_25957905:~... [4] https://news.ycombinator.com/item?id=25940064#unv_25957481:~:text=use.-,Hell%2C%20in%20my%20main%20project%20I've%20been%20unable%20to%20use%20any%20version%20of%20gdb%20%26%20lldb%20for%20something%20like%20two%20months%20as%20both%20segfault%20a%20couple%20seconds%20after%20reaching%20a%20breakpoint,for%20some%20reason.%20It's%20a%20shitshow https://news.ycombinator.com/item?id=25940064#unv_25957481:~.... [5] https://news.ycombinator.com/item?id=25940064#unv_25957428:~:text=The%20problem%20of%20debugging%20has%20become,have%20some%20kind%20of%20async%20mechanism https://news.ycombinator.com/item?id=25940064#unv_25957428:~.... [6] https://news.ycombinator.com/item?id=25940064#unv_25957481:~:text=if%20debuggers%20took%20less%20time%20to%20start%20than%20a%20full%20%22add%20print%20%2D%3E%20recompile%20%2D%3E%20relaunch%20app%22%20cycle%20as%20is%20my%20experience%20with%20C%2B%2B%2C,they%20would%20certainly%20get%20more%20use.,-Hell%2C https://news.ycombinator.com/item?id=25940064#unv_25957481:~... [7] https://lightrun.com/debugging/remote-debugging-re-examined-for-the-wfh-era/ https://lightrun.com/debugging/remote-debugging-re-examined-... [8] https://zipkin.io/ https://zipkin.io/ [9] https://www.jaegertracing.io/ https://www.jaegertracing.io/

57 points by luu 6y ago

I recently discovered https://github.com/weirdNox/emacs-gdb/ https://github.com/weirdNox/emacs-gdb/ . The installation is a bit unconventional compared to the usual Emacs package installation process, but works pretty well. This recreates the Visual Studio style workflow described in https://twitter.com/pervognsen/status/1098453808651202560 https://twitter.com/pervognsen/status/1098453808651202560 and https://youtu.be/0woxSWjWsb8?t=254 https://youtu.be/0woxSWjWsb8?t=254

flohofwoe 6y ago

Strange that VSCode + debugger frontend extensions (mentioned in the first part) caused such trouble, it's working flawlessly so far for me for mixed Zig/C projects, across Windows, macOS and Linux (Ubuntu 20) The inspection capabilities in the VSCode debugger are very bare bones though, that's true. At least the variable view panel could need some work.

IAmAtWork 6y ago
I was so goo at debugging the hardware I underestimated just how difficult will it be to switch to software even when you really good at that language. But set up is important esp for web technologies as they are buggy by default. Interestingly I never had issue with C

dan-robertson 6y ago

I think there are a few sides to this problem: 1. Debuggers are in some sense anti-unix. They only work well when they are thoroughly integrated with the rest of your environment. Trying to have some debugger program like gdb and then talking to it from emacs or a terminal or something will be a big pain. Emacs is also anti-unix but seems to have enough mass that it doesn’t matter so much (or maybe the debugger and emacs fighting for importance is problematics) 2. Getting a debugger to work well is hard. Apart from needing information to work out what bit of code is executing (and passing all that information through weird compilation steps or linking), the debugger needs to understand the memory layout of objects and interpret some subset of the language so that people can enter eg watch expressions. This is hard when the compiler and debugger are quite separate and just agree on the format for possible debug information. Lack of integration hurts again 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? I guess Java too? Lots of people end up debugging with prints and that just isn’t so effective. I think I’ve barely used a debugger for more than trivial websites in the last 10 years. 4. The problem of debugging has become harder: there are now more threads in programs and it is more common for languages to have some kind of async mechanism. If you naively debug that, you’ll see crap stacktraces (a few frames sat atop a scheduler) and execution may move randomly between threads in a pool. I feel like most debuggers can’t cope. (I guess website debuggers do understand async better and there are also new inventions like reversible debugging with rr, but the problem with integrating a debugger with a language or an editor remains.)

jcelerier 6y ago
> 1. Debuggers are in some sense anti-unix. it's not a problem when you accept that the unix philosophy is extremely far from the holy grail of software design. "things that do one thing well" certainly has good sides for specific problems, mainly quick'n'dirty linear text processing dataflows, but is atrocious for other problems (anything that need integration and discoverability: art software, web browsers, or revolves more around user interaction than computing something) > 3. Some people are so used to not having a debugger that they don’t know what they’re missing. Debuggers work well for what, windows and websites? if debuggers took less time to start than a full "add print -> recompile -> relaunch app" cycle as is my experience with C++, they would certainly get more use. Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow.
- DoofusOfDeath 6y ago
  > Hell, in my main project I've been unable to use any version of gdb & lldb for something like two months as both segfault a couple seconds after reaching a breakpoint for some reason. It's a shitshow. I'm really surprised. In my experience it's really rare for either of those debuggers to crash, let alone for both to crash on the same target. A bit of a tangent, but would you mind sharing some details about your compiler / OS / debugger / target-hardware versions?
  - tkinom 6y ago
    Same here. CLI version of gdb has worked extremely reliable for me across multiple projects and architectures (x86, arm, arm64, etc). I have yet to encounter a bug can't be debug with gdb with some test automation + gdb script with conditional breakpoints / hw breakpoints. As long as I can reproduce the issue with test automation, I can debug it with gdb. Most complex bugs are I have to debug was multiple threads (20+) memory leak shows up after days of testing. I don't use GUI gdb. cli + gdb script is the best and most reliable debugging environment. I don't add printf to my code anymore, a new gdb breakpoint script + with proper debug build can replace the printf anywhere and anytime.

jcalabro 6y ago

If you use Windows at all, you should check out RemedyBG[0], it's excellent. But Windows-only. [0] https://remedybg.itch.io/remedybg https://remedybg.itch.io/remedybg

corysama 6y ago
They say “early access”. Can anyone speak to its current stability/issues?

GartzenDeHaes 6y ago

I continue to be shocked at the lack of productive development tools on linux. My current c/c++ toolset is: a makefile generator that I wrote after years of wasting time on autotools problems, Anjuta for debugging and rudimentary editing, and Visual Studio 2008 on Windows XP running in VirtualBox for most productive work (it's a cross platform project).

Cloudef 6y ago
vim, gcc, gdb, radare2, valgrind, callgrind, helgrind, coreutils, git, make

bjg 6y ago

https://www.gdbgui.com/ https://www.gdbgui.com/ is another good frontend for gdb.

kuter 6y ago

I don't think GDB is too bad. Most people probably don't use watch expressions, conditional breakpoints etc.

madhadron 6y ago
> Most people probably don't use watch expressions, conditional breakpoints etc. That's an indictment of the available debugger interfaces that they wouldn't.
modeless 6y ago
I use them all the time in Chrome dev tools where there is a nice GUI for them and they actually work properly.
Cloudef 6y ago
They become pretty much essential when reversing or debugging a program you dont have source for.

dummy_physicist 6y ago

Some years ago I learned about ProDBG[0] and was pretty excited. It is going through a rewrite, I hope it gets usable soon. [0] https://github.com/emoon/ProDBG https://github.com/emoon/ProDBG

slezyr 6y ago

Qt Creator's debugger is almost perfect for my goals. It's, probably, the most user-friendly. However, I wish I could feed gdb commands directly to it.

jcelerier 6y ago
> However, I wish I could feed gdb commands directly to it. you can: while debugging, enable "Debug Log" (in the View menu), and this adds a pane where you can input gdb command. Output is not very pretty though.

saagarjha 6y ago

> It doesn't actually seem to be trying to write "/tmp". It actually doesn't issue any syscalls at all when I press "Debug Main Project" and trigger the message. Perhaps a subprocess is doing this?

dvirsky 6y ago

It's worth mentioning that vim has added debugger integration support as a plugin, but that plugin is available with vim by default, you just need to enable it. It's not perfect but it's usable - you can set breakpoints visually and save/load them, you can step debug inside your code window (gdb is actually running in another vim window and can be controlled directly) and you can see the value of expressions in your code window. This is a nice guide to it: https://www.dannyadam.com/blog/2019/05/debugging-in-vim/ https://www.dannyadam.com/blog/2019/05/debugging-in-vim/

wallstprog 6y ago

The one thing I really miss about Windows is the Visual Studio debugger -- it was frickin' awesome even back w/VS 2005 and I have to believe it's gotten better. On Linux I use ddd, and while it's definitely quirky (in that weird X way), it works just fine. I would guess that many of the poster's problems have to do with Linux's mediocre GUI support in general. I've recently switched to doing development on Ubuntu (vs. RH/CentOS) and all the GUI stuff works much better in that environment, incl. ddd. I haven't tried Eclipse's C/C++ debugger, but its Perl debugger (part of EPIC) is quite nice and works well on both Mac and Linux.

tomgs 6y ago

Disclaimer (and a bit of context): I work for a company that builds a special type of debugger, aimed at debugging live applications in production. As one would expect, we've spent an enormous amount of time thinking about debuggers, how they work from the inside and what they contribute to the general experience of developing software. Debuggers are, for developers well-versed in working with them, priceless tools (see [1] for an example from this very thread). There's so, so much value in walking through a program not only in one's head (as well-put by pg at one time[2]), but by using a tool that enforces a more structured, "formal" process for program exploration. I use it when trying to understand how code I write actually looks like IRL, but also - and maybe more so - for understanding code OTHER PEOPLE wrote with better context than any piece of documentation or simply reading the code would ever give me. But - as the article and some[3] of[4] the[5] comments[6] here point out - it has warts (quick plug - I recently wrote a blog post[7] that details my perspective on remote debuggers and how they can be better). One thing that I didn't see mentioned in this thread or in the article, and is a real PITA, is performance. Debuggers are not built to deal with performance problems - or collection of temporal data, for that matter - at all. Consider how one might go about debugging a real-life performance issue, especially in the context of modern applications - many threads, many hosts, many replicas of the same service, etc. You probably have a tracer - something like Zipkin[8] or Jaeger[9] - that helps you to break apart latency issues in your endpoints. You also probably have a set of instrumented metrics (graphed inside your APM, perhaps) for quick observation when something is not reacting as fast as you expect it to. But sometimes they don't tell the full story - there's just too many possible edge cases. Performance issues can be caused by data structures exploding in size, causing degraded performance and OOMs. They can be caused by one method, in a chain of dozens of different, inter-connected ones, that is especially slow. It can be related to non-optimized SQL queries (maybe hidden behind an ORM). It can be a weird code path - one the developer did not expect, and did not test for - that gets triggered by users with very specific characteristics. Hard. [1] https://news.ycombinator.com/item?id=25960923#unv_25960923:~:text=The%20debugger%20is%20the%20main%20reason,for%20JVM%20or%20dynamic%20language%20stuff https://news.ycombinator.com/item?id=25960923#unv_25960923:~...... [2] http://www.paulgraham.com/head.html http://www.paulgraham.com/head.html [3] https://news.ycombinator.com/item?id=25940064#unv_25957905:~:text=gdb%20and%20lldb%20don't%20work%20great,where%20multiple%20threads%20are%20executing%20concurrently https://news.ycombinator.com/item?id=25940064#unv_25957905:~... [4] https://news.ycombinator.com/item?id=25940064#unv_25957481:~:text=use.-,Hell%2C%20in%20my%20main%20project%20I've%20been%20unable%20to%20use%20any%20version%20of%20gdb%20%26%20lldb%20for%20something%20like%20two%20months%20as%20both%20segfault%20a%20couple%20seconds%20after%20reaching%20a%20breakpoint,for%20some%20reason.%20It's%20a%20shitshow https://news.ycombinator.com/item?id=25940064#unv_25957481:~.... [5] https://news.ycombinator.com/item?id=25940064#unv_25957428:~:text=The%20problem%20of%20debugging%20has%20become,have%20some%20kind%20of%20async%20mechanism https://news.ycombinator.com/item?id=25940064#unv_25957428:~.... [6] https://news.ycombinator.com/item?id=25940064#unv_25957481:~:text=if%20debuggers%20took%20less%20time%20to%20start%20than%20a%20full%20%22add%20print%20%2D%3E%20recompile%20%2D%3E%20relaunch%20app%22%20cycle%20as%20is%20my%20experience%20with%20C%2B%2B%2C,they%20would%20certainly%20get%20more%20use.,-Hell%2C https://news.ycombinator.com/item?id=25940064#unv_25957481:~... [7] https://lightrun.com/debugging/remote-debugging-re-examined-for-the-wfh-era/ https://lightrun.com/debugging/remote-debugging-re-examined-... [8] https://zipkin.io/ https://zipkin.io/ [9] https://www.jaegertracing.io/ https://www.jaegertracing.io/