Hacker News Reader

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

This is a really good point - programmers seem to prefer making "dead"/batch-processing programs over "living", interactive, persistent systems (according to Steve Yegge's definition of those[1]).

This style, in addition to being very Unix-y, also lends itself really well to printf debugging - you just add printfs, recompile, and re-run.

I build "live" programs, and make heavy use of the debugger - although that might be because of tight integration of my debugger with the rest of my tools - although that might be because other users of this language tend to prefer the live style and build their tools to adapt.

[1] http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.ht...

I also build live programs, I just have a simple system that reloads its state from before a crash upon statup - that ends up working fine 99% of the time and I can get back to just before the faulty interaction without loosing time.

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

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.

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

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/phot...

(lldb does not give me an error message, just segfault)

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++.

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).

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.

I agree that debuggers being anti-unix isn’t a problem if they embrace that and integrate deeply with their environment but such a phrase does not describe gdb or lldb.