[Bug 216648] New: man 5 core incorrectly states circumstances in which a core is not produced

[Bug 216648] New: man 5 core incorrectly states circumstances in which a core is not produced

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216648

            Bug ID: 216648
           Summary: man 5 core incorrectly states circumstances in which a
                    core is not produced
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: veluca93@gmail.com
        Regression: No

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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216648] man 5 core incorrectly states circumstances in which a core is not produced

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216648

Alejandro Colomar (man-pages) (alx.manpages@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alx.manpages@gmail.com

--- Comment #1 from Alejandro Colomar (man-pages) (alx.manpages@gmail.com) ---
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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216648] man 5 core incorrectly states circumstances in which a core is not produced

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216648

--- Comment #2 from Luca Versari (veluca93@gmail.com) ---
> 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.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 216648] man 5 core incorrectly states circumstances in which a core is not produced

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=216648

Luca Versari (veluca93@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |CODE_FIX

--- Comment #3 from Luca Versari (veluca93@gmail.com) ---
I believe this has been fixed now.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.