Compressing the Core Files During Core Generation

GDB and trouble with core dumps

I've solved this particular issue, thanks largely to WhozCraig, whom suggested that GDB was behaving as it should have when being force-fed an LZ4 compressed corefile. If Craig would be so kind as to post a solution saying something similar, I'd be happy to give him that big 'ol check mark I'm taking all the credit, though. Bwahahaha!

The easiest solution is to start gdb via a subroutine named coredumpctl along with the crashed program's PID, a la

$coredumpctl gdb PID HERE

This vexes me, Arch, and I may migrate over to Gentoo because of it.

reduce core dump size on linux

Consider using Breakpad: https://code.google.com/p/google-breakpad/
https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad :

Breakpad is a library and tool suite that allows you to distribute an
application to users with compiler-provided debugging information
removed, record crashes in compact "minidump" files, send them back to
your server, and produce C and C++ stack traces from these minidumps.
Breakpad can also write minidumps on request for programs that have
not crashed.

How to change the path of Oracle JVM core dump file?

The answer depends on your Java version and the OS platform.

For Java 8 on Linux, the location is hard-wired to the current directory.

For Java 11 and Java 17 on Linux, the JVM uses the Linux "/proc/sys/kernel/core_pattern" mechanism described in Changing location of core dump and other places.

On BSD (e.g. Darwin), the location is Java version dependent: either "/core" (hard wired) or a location provided by the OS kernel.

On AIX and Windows it seems to use the current directory in all Java versions.

And so on.

^{(The above is from looking at the OpenJDK source code for Java 8, 11 and 17. Note that the relevant code changed substantially between Java 8 and 11.)}

---

Related Topics