4 ms·

> 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 br

> 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.
- TwoBit 6y ago
  No offense but I'm guessing your debugging needs aren't as complicated as some others' needs.
jcelerier 6y ago
amd64 arch linux, so latest version of clang++ and gdb/lldb. Project built against c++20. Here's what I'm getting from gdb: https://twitter.com/jcelerie/status/1348259387127824387/photo/1 https://twitter.com/jcelerie/status/1348259387127824387/phot... (lldb does not give me an error message, just segfault)
- DoofusOfDeath 6y ago
  Interesting. I just took a look at the line of gdb code that's crashing on you. I'm only slightly familiar with gdb's internals, but I can imagine a bunch of different sources for this bug: - gdb has a misconception about which c++ ABI was used when compiling the target program, or - your program is stomping on an object's vtable pointer, leading gdb to follow invalid pointers when trying to parse the object's RTTI, or - there's a bug in clang++, or - there's a mix of abi versions in your program's code, perhaps because of unexpected linking issues (static or dynamic), or perhaps because of inconsistent compiler flags when building your code I'm curious what happens if you build your program with g++ instead of clang++.
  - jcelerier 6y ago
    My program has no issues running with asan / ubsan so I don't think it would be a vtable / memory overwrite issue as those are pretty much 100% detected. Also I build my whole stack (except glibc and libx11 basically) statically with the same flags so I doubt there could be an abi problem (and LTO builds would complain).
    - DoofusOfDeath 6y ago
      Ugh, this is so frustrating. I'd love to solve this mystery, but I can't easily set up an environment for it right now. Best of luck. I hope you'll post an update if you ever get to the bottom of it.

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.

TwoBit 6y ago
No offense but I'm guessing your debugging needs aren't as complicated as some others' needs.

jcelerier 6y ago

amd64 arch linux, so latest version of clang++ and gdb/lldb. Project built against c++20. Here's what I'm getting from gdb: https://twitter.com/jcelerie/status/1348259387127824387/photo/1 https://twitter.com/jcelerie/status/1348259387127824387/phot... (lldb does not give me an error message, just segfault)

DoofusOfDeath 6y ago
Interesting. I just took a look at the line of gdb code that's crashing on you. I'm only slightly familiar with gdb's internals, but I can imagine a bunch of different sources for this bug: - gdb has a misconception about which c++ ABI was used when compiling the target program, or - your program is stomping on an object's vtable pointer, leading gdb to follow invalid pointers when trying to parse the object's RTTI, or - there's a bug in clang++, or - there's a mix of abi versions in your program's code, perhaps because of unexpected linking issues (static or dynamic), or perhaps because of inconsistent compiler flags when building your code I'm curious what happens if you build your program with g++ instead of clang++.
- jcelerier 6y ago
  My program has no issues running with asan / ubsan so I don't think it would be a vtable / memory overwrite issue as those are pretty much 100% detected. Also I build my whole stack (except glibc and libx11 basically) statically with the same flags so I doubt there could be an abi problem (and LTO builds would complain).
  - DoofusOfDeath 6y ago
    Ugh, this is so frustrating. I'd love to solve this mystery, but I can't easily set up an environment for it right now. Best of luck. I hope you'll post an update if you ever get to the bottom of it.