Bug 216648
| Summary: | man 5 core incorrectly states circumstances in which a core is not produced | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Luca Versari (veluca93) |
| Component: | man-pages | Assignee: | documentation_man-pages (documentation_man-pages) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | alx |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
Hi Luca, Do you have any experiments demonstrating the actual behavior? Could you show them? And do you suggest any specific patch for that page? You may consider reading <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING> if you would like to send a patch for the page. Thanks! Alex > Do you have any experiments demonstrating the actual behavior? Could you show > them? On a system with systemd (or where /proc/sys/kernel/core_pattern is configured to pipe to a program), run `ulimit -c 0`, then run a program that segfaults (writing `int main() { *(volatile int *)0; }` in a `segfault.c` file and running `gcc segfault.c; ./a.out` should be sufficient). This creates a core dump, despite RLIMIT_CORE being 0. > And do you suggest any specific patch for that page? Something like adding ", unless the system is configured to pipe core dumps to a program" in that bullet point should be sufficient. I believe this has been fixed now. |
As per title, the `core` manpage states: There are various circumstances in which a core dump file is not produced: [...] * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell's ulimit command (limit in csh(1)). However, this is not actually correct when core dumps are piped to a program, as the section below states ... * The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism.