Even if the rest of GDB remains a mystery to you, you can learn the two simplest and most useful functions: 1) how to create a backtrace, and 2) how to create a core dump. That way you can always send a bug report with lots of detail to somebody else for analysis.

> 2) how to create a core dump

This is a PITA under Linux, I figured this out but nor happy I had to look.

I wish Linux was like OpenBSD, where you get core files by default. This give me yet another reason to switch to OpenBSD, I only wish some other issues I am having with OpenBSD could get solved.

> OpenBSD, where you get core files by default

By this, are you referring to the behavior: "By default, this memory image is written to a file named programname.core in the working directory, provided the terminated process had write permission in the directory[...]" (from https://man.openbsd.org/core.5) ?

Also, do you know if there's a way to obtain a core file from a running process on OpenBSD? I don't see a port of gcore, and (e)gdb on OpenBSD doesn't support the generate-core-file command (it says, "Can't create a corefile").

Yes,

kill -ABRT pid

should do it

Good idea to just abort it. :)

However, I tried your suggestion from another terminal, and gdb appears to shield the program somehow. What ended up working is running "signal SIGABRT" from within gdb.

One thing that's still lacking is gcore's ability to take a snapshot of the core without killing the program. "Unlike after a crash, after gcore finishes its job the program remains running without any change." https://www.man7.org/linux/man-pages/man1/gcore.1.html

What did you figure out as a solution?

I've previously configured `/proc/sys/kernel/core_pattern` to generate core dumps by default (and not pipe them to a core dump collection program, which may be useful for error reporting but is rarely what I want).

There's also `gcore` for doing on-demand core dumps.

I wish it were possible to configure core dump behaviour per-process (or something similar).

This is what I did:

ulimit -S -c unlimited

sudo sysctl -w kernel.core_pattern=core

took me a while to figure this out, HTH

Thanks! I also see there's a `/proc/sys/kernel/core_uses_pid` that will make you get `core.PID` files, without having to mess around with core patterns - seems useful.

What do you use for debugging instead?

Print statements, haha.

My code is for linear algebra stuff, so it is pretty much a straight shot through/filling in some RCI loop most of the time, I usually just have to find which OpenMP or MPI barrier is misbehaving.

Print statements are really really good for debugging because they give you a timeline of "things that happened that I was interested in".

It's like using Google Maps to see the general shape of a landscape. A debugger is generally more like Google Streetview - you get strictly more detail and it makes some problems way easier to solve. It's just not always the easiest way to get an overview.

With that in mind, though, GDB's "Dynamic Printf" is pretty cool: https://sourceware.org/gdb/onlinedocs/gdb/Dynamic-Printf.htm...

You basically configure GDB to add printfs to the program you're debugging, without having to rebuild it. You just run under GDB and the prints will run. As a bonus, you can also interact using normal debugging commands too.

Never underestimate the power of print statements for debugging, that being said, the gdb-based "poor man's profiler" has also been a life saver.

Print statements indeed. That's when the source project is at your fingertips. Otherwise, it's more about collecting and figuring out the conflicting state, than locating the actual problem. So saving a core/logs is paramount.