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?
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.
https://twitter.com/jcelerie/status/1348259387127824387/phot...
(lldb does not give me an error message, just segfault)
- 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++.
Best of luck. I hope you'll post an update if you ever get to the bottom of it.