How to debug D on Linux

Roguish nospam at nospam.net
Wed Jan 13 14:58:38 UTC 2021


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.


More information about the Digitalmars-d-learn mailing list