News for hackers. Stuff that matters.

A comment on Debugging with GDB. Parent comment

Re:Debugging with GDB by 0xbadcafebee on Monday March 21, 2022 @11:35AM (#30755263)
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.
[ Parent | on HN ]
Re:Debugging with GDB by jmclnx on Monday March 21, 2022 @02:28PM (#30757836)
> 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.

[ Parent | on HN ]
Re:Debugging with GDB by begriffs on Monday March 21, 2022 @03:50PM (#30758880)
> 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").

[ Parent | on HN ]
Re:Debugging with GDB by jmclnx on Monday March 21, 2022 @06:51PM (#30760782)
Yes,

kill -ABRT pid

should do it

[ Parent | on HN ]
Re:Debugging with GDB by begriffs on Monday March 21, 2022 @11:38PM (#30762489)
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

[ Parent | on HN ]
Re:Debugging with GDB by mark_undoio on Monday March 21, 2022 @03:24PM (#30758555)
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).

[ Parent | on HN ]
Re:Debugging with GDB by jmclnx on Monday March 21, 2022 @06:48PM (#30760758)
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

[ Parent | on HN ]
Re:Debugging with GDB by mark_undoio on Wednesday March 23, 2022 @10:48AM (#30779004)
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.
[ Parent | on HN ]