A few more debugging tips - run debugger automatically on linux

Core D Development Statistics

• 12 bugs fixed
• 12 bugs and enhancement requests opened
• Bugs closed WONTFIX:
  • DMD allows variables to be declared as pure
• Bugs closed INVALID:
  • Assertion failed: (type && init), function getConstInitializer, file declaration.c, ine 2295
• 33 pull requests merged into the language: 30 into DMD and druntime and 3 into Phobos
• 8 pull requests merged into the website.

In the community

Community announcements

• LDC 1.32.0
• Objective-C D metal binding
• How to set up D and GLFW/OpenGL project on MacOS, Linux and Windows | [video]

See more at the announce forum.

Tip of the Week

I previously wrote a few gdb tips and want to add a few more here and update some of that. I suggest you skim the old tips there, it isn't long.

druntime has changed its GC signals in recent versions, so my .gdbinit looks like this now:

# old druntime gc signals
handle SIGUSR1 noprint
handle SIGUSR2 noprint

# new druntime gc signals
handle SIG33 noprint
handle SIG34 noprint

So routine GC behavior won't trigger the debugger.

I also like to use a helper script which I call gdbr:

#!/bin/bash

gdb -q -ex run -ex quit --args $* --DRT-trapExceptions=0

This runs the given program with the given arguments, but:

• Automatically runs it without waiting for input
• Automatically exits the debugger when the program completes normally
• Tells druntime not to print uncaught exceptions, meaning the debugger can see them at the throw site

This means running gdbr foo is just like running ./foo except if it crashes, the debugger is right there, ready and waiting to be used at the crash site.

Another thing you might consider doing is enabling core dumps and even setting a PROMPT_COMMAND - which is run before each time the bash shells hows its prompt - to check for a segfault return and fire up the debugger on the core dump if it happened. This varies a bit by linux distro, but it could be like:

The PROMPT_COMMAND is this:

ulimit -c unlimited # enable core dumps in this session
# and now enable the automatic command
export PROMPT_COMMAND=' if [[ $? -eq 139 ]]; then gdb -q -ex where -ex quit $PROGRAM_NAME core; fi'

You'll gave to set the export PROGRAM_NAME=./whatever as part of the setup too. Then run your program in this shell. If it crashes, this command will see it - a return value of 139, aka -11, indicates a SIGSEGV exit - and fire up the debugger. It uses the where then quit commands automatically, meaning it will dump the backtrace and return you immediately to your command prompt.

Side effects and caveats:

• If you press enter again without running another command, it will show the backtrace again, since the $? variable will be unchanged.
• If you are on a distro that sets up crash reports, your core file might not be called core. Perhaps try coredumpctl debug instead of the gdb command in PROMPT_COMMAND if you have systemd on your distro. Generally speaking, this is configurable by the kernel. More on this soon.
• The core dump will still be there for future inspection. You might want to delete it if you're done with it.

The core filename is configurable. The default is often ./core but distros with crash reports often change this. You might check cat /proc/sys/kernel/core_pattern to see what it is configured on your system. And what's very interesting about this is it need not be a filename.... it can be a pipe. This is what systemd and the coredumpctl depends on.

If you set it to a pipe, you can direct the file wherever you want and trigger something on demand. This program is triggered by the kernel and is run in a global context as root, without the same controlling terminal as the crashed program. So doing the inline backtrace info there in the terminal is another exercise - you'd probably want to have your active terminal configured to opt into the info - but it'd be possible to set it up to run your debugger on demand too.

Details here: https://man7.org/linux/man-pages/man5/core.5.html

See https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Core_files for some more information.

Conclusion

Personally, I prefer my gdbr script. It is a local solution to a local problem and the script makes running it very easy without needing a core dump file. But the automatic shell command or even the system-wide jit debugger the kernel enables might be fun for you to explore. A CI runner or running server capturing coredumps on demand is probably better than just always having the interactive debugger standing by, but when actively working on something, the "build, debug+run" pattern is nice to have and easy to do from a shell as well as IDEs.

If you're trying to set segfault signal handlers, I encourage you to consider these options instead.