On Wednesday, 13 January 2021 at 14:13:11 UTC, Adam D. Ruppe
wrote:
-debug enables the `debug` keyword inside the D code itself.
This lets you bypass other rules temporarily. For example
...
It does NOT do anything related to running D in debuggers like
gdb, it just enables code guarded by that debug keyword.
Thanks, that's very clear.
* Segfaults should be run inside the debugger to get the stack
trace. If your program did "Segmentation fault (core dumped)",
you can fire up gdb after the fact on it. Check that directory
for a .core file and then run `gdb program that.core` to
inspect it.
It seems on my system no .core file gets generated, even though
the program outputs "Segmentation fault (core dumped)". At least
it's not present in the directory from where I compile and run
the program, nor is it in /var/lib/systemd/coredump where,
according to systemd-coredump's documentation, it should go by
default. Anyway, I'm guessing this is a config problem with my
Linux, rather than anything to do with D's compiler or runtime.
* Running a program in gdb may sometimes say "program received
SIGUSR1" and pause.
The commands
handle SIGUSR1 noprint
handle SIGUSR2 noprint
will skip this. SIGUSR1/2 are used by the GC when doing
collections so you probably don't care about it. You can put
those commands i your ~/.gdbinit to run every time.
* Running `gdb --args ./yourprogram --DRT-trapExceptions=0`
will break on any uncaught exception so you can inspect that
stuff. Super useful if you get one of those.
Yes! Excellent tips these. Thank you.
