3 ms·

> [Re: gdb -tui] Unfortunately, it's pretty buggy I feel like this article gave up way too fast on gdb's tui mode, especially given that gdb works and tui didn

by dahart 6y ago

> [Re: gdb -tui] Unfortunately, it's pretty buggy I feel like this article gave up way too fast on gdb's tui mode, especially given that gdb works and tui didn't crash like half the debuggers in the list, other than "the command tui disable crashes gdb." which I can't reproduce. The complaints about rendering and arrow keys are very easy to overlook with just a few tui mode hotkeys. ctrl-x-a toggles tui, ctrl-x-o toggles arrow-key focus between code and the gdb command line, and ctrl-l repaints whenever the rendering gets borked. Those three things cover all the concerns listed here. The single most important thing about gdb, however, is the .gdbinit file. Being able to script your debug session is hands down the best thing about gdb. Bugs that require several steps to repro can be completely automated in gdb. You have conditionals and looping available in the debug script, this is very powerful. I suspect a bunch of the debuggers listed don't really support such a workflow. Since I work in a CUDA environment often, it's also nice that cuda-gdb mirrors gdb, I can have scripting & tui mode for both.

DoofusOfDeath 6y ago
> I feel like this article gave up way too fast on gdb's tui mode, especially given that gdb works and tui didn't crash like half the debuggers in the list, other than "the command tui disable crashes gdb." which I can't reproduce. I've had the same conundrum for a various categories of development tools on Linux: For a particular category (e.g., remote debugging, Vim C++ autocomplete system, etc.), an initial search uncovers 3-10 software combinations that people have documented as working. And when I work through the list, trying to find one that works for me, I often hit problem after problem. It's hard to know if (a) that particular recipe is no longer workable, (b) there's something about my particular setup that will forever damn that approach, or (c) I just need to keep working through the problems until I finally get things working. So it's hard to know how long to bang away at a particular recipe to determine if it's (a), (b), or (c). The unfortunate result is I often run out of time for the investigation, and fall back to using Vim + gdb + ctags for developing on remote servers. Mostly I'm just surprised that Visual Studio in 1999 gave me a better debugging experience than I've been able to cobble together on Linux in 2020.
- ensiferum 6y ago
  I recommend Clion. It simply just works.
  - jamii 6y ago
    It doesn't work very well for me - https://scattered-thoughts.net/writing/the-state-of-linux-debuggers/#jetbrains-clion https://scattered-thoughts.net/writing/the-state-of-linux-de... This is perhaps related to using zig, but it's frustrating that gdb itself works fine with zig but each gdb frontend manages to break in different ways.
  - renox 6y ago
    Good for you, but at work I’m not so lucky (large C++ project == CLion is so slow to be only usable if you’re a zen master). For debugging, gdb -tui works for me (once I’ve learned to refresh the display after an output). For coding, VSCode’s is much more responsive than CLion but its code navigation is inconsistent and it use >30GB of RAM once a week randomly (60 GB last week!).. I’m thinking about going back to Vim :-(
    - xxpor 6y ago
      I've found clangd to be much more responsive than the built in LSP fwiw. No comment on memory though, my remote dev env has 384 gb so I don't really pay much attention :/
    - ensiferum 6y ago
      Interested to know what is the size of the project? I'm currently working on something small about 60kloc of my code, another 60k in third_party and Qt5 as additional dep. There are a few hiccups every now and then when the Clion UI freezes for a few seconds but other than that it's been working really great.
jamii 6y ago
Unfortunately ctrl-x-a also reproduces that crash for me - https://paste.sr.ht/~jamii/a1cd701eae0c2416eb9750d7c559e4b3b1383897 https://paste.sr.ht/~jamii/a1cd701eae0c2416eb9750d7c559e4b3b...
- db48x 6y ago
  If you can reproduce the crash, it's an ideal candidate to record with rr and try to debug :)
- dahart 6y ago
  Oh I believe it crashes, but I’d speculate wildly this perhaps indicates some bad combo of gnu with other tools, or a missing lib, or a side effect of system customization, or a beta distro, or something like that maybe? Are you sure it’s an issue with gdb? I’ve used gdb a bunch, mostly on lots of Ubuntu machines, I haven’t seen tui crashing like that myself.
  - jamii 6y ago
    > some bad combo of gnu with other tools, or a missing lib, or a side effect of system customization, or a beta distro, or something like that maybe? Oh, I'm sure it is. Debugging it would probably be good practice. I'll just open my working debugger...
- tromey 6y ago
  This was https://sourceware.org/bugzilla/show_bug.cgi?id=25348 https://sourceware.org/bugzilla/show_bug.cgi?id=25348, fixed in June. I believe the fix is in the latest release.

by dahart 6y ago

DoofusOfDeath 6y ago

> I feel like this article gave up way too fast on gdb's tui mode, especially given that gdb works and tui didn't crash like half the debuggers in the list, other than "the command tui disable crashes gdb." which I can't reproduce. I've had the same conundrum for a various categories of development tools on Linux: For a particular category (e.g., remote debugging, Vim C++ autocomplete system, etc.), an initial search uncovers 3-10 software combinations that people have documented as working. And when I work through the list, trying to find one that works for me, I often hit problem after problem. It's hard to know if (a) that particular recipe is no longer workable, (b) there's something about my particular setup that will forever damn that approach, or (c) I just need to keep working through the problems until I finally get things working. So it's hard to know how long to bang away at a particular recipe to determine if it's (a), (b), or (c). The unfortunate result is I often run out of time for the investigation, and fall back to using Vim + gdb + ctags for developing on remote servers. Mostly I'm just surprised that Visual Studio in 1999 gave me a better debugging experience than I've been able to cobble together on Linux in 2020.

ensiferum 6y ago
I recommend Clion. It simply just works.
- jamii 6y ago
  It doesn't work very well for me - https://scattered-thoughts.net/writing/the-state-of-linux-debuggers/#jetbrains-clion https://scattered-thoughts.net/writing/the-state-of-linux-de... This is perhaps related to using zig, but it's frustrating that gdb itself works fine with zig but each gdb frontend manages to break in different ways.
- renox 6y ago
  Good for you, but at work I’m not so lucky (large C++ project == CLion is so slow to be only usable if you’re a zen master). For debugging, gdb -tui works for me (once I’ve learned to refresh the display after an output). For coding, VSCode’s is much more responsive than CLion but its code navigation is inconsistent and it use >30GB of RAM once a week randomly (60 GB last week!).. I’m thinking about going back to Vim :-(
  - xxpor 6y ago
    I've found clangd to be much more responsive than the built in LSP fwiw. No comment on memory though, my remote dev env has 384 gb so I don't really pay much attention :/
  - ensiferum 6y ago
    Interested to know what is the size of the project? I'm currently working on something small about 60kloc of my code, another 60k in third_party and Qt5 as additional dep. There are a few hiccups every now and then when the Clion UI freezes for a few seconds but other than that it's been working really great.

jamii 6y ago

Unfortunately ctrl-x-a also reproduces that crash for me - https://paste.sr.ht/~jamii/a1cd701eae0c2416eb9750d7c559e4b3b1383897 https://paste.sr.ht/~jamii/a1cd701eae0c2416eb9750d7c559e4b3b...

db48x 6y ago
If you can reproduce the crash, it's an ideal candidate to record with rr and try to debug :)
dahart 6y ago
Oh I believe it crashes, but I’d speculate wildly this perhaps indicates some bad combo of gnu with other tools, or a missing lib, or a side effect of system customization, or a beta distro, or something like that maybe? Are you sure it’s an issue with gdb? I’ve used gdb a bunch, mostly on lots of Ubuntu machines, I haven’t seen tui crashing like that myself.
- jamii 6y ago
  > some bad combo of gnu with other tools, or a missing lib, or a side effect of system customization, or a beta distro, or something like that maybe? Oh, I'm sure it is. Debugging it would probably be good practice. I'll just open my working debugger...
tromey 6y ago
This was https://sourceware.org/bugzilla/show_bug.cgi?id=25348 https://sourceware.org/bugzilla/show_bug.cgi?id=25348, fixed in June. I believe the fix is in the latest release.