[PATCH v2] abort: clarify consequences of calling abort

[PATCH v2] abort: clarify consequences of calling abort

[Tomáš Golembiovský]

Clarify that atexit/on_exit are not called because those are called only
on normal process termination (as documented on their respective manual
pages).

Clarify the status reported by wait*() functions. The requirement comes
from POSIX specification.

Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
---
 man3/abort.3 | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/man3/abort.3 b/man3/abort.3
index c63eace5e..2454e186d 100644
--- a/man3/abort.3
+++ b/man3/abort.3
@@ -47,6 +47,17 @@ function will still terminate the process.
 It does this by restoring the default disposition for
 .B SIGABRT
 and then raising the signal for a second time.
+.PP
+As with other cases of abnormal termination the functions registered with
+.BR atexit "(3) and " on_exit (3)
+are not called.
+The status made available to
+.BR wait "(2), " waitid "(2), or " waitpid (2)
+by
+.BR abort ()
+shall be that of a process terminated by the
+.BR SIGABRT
+signal.
 .SH RETURN VALUE
 The
 .BR abort ()
-- 
2.41.0

Re: [PATCH v2] abort: clarify consequences of calling abort

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Hi Tomáš,

At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
[...]
> Clarify the status reported by wait*() functions. The requirement
> comes from POSIX specification.
[...]
> +The status made available to
> +.BR wait "(2), " waitid "(2), or " waitpid (2)
> +by
> +.BR abort ()
> +shall be that of a process terminated by the
> +.BR SIGABRT
> +signal.
[...]

I believe Alex's preference in the Linux man-pages project is to
document what is actually implemented, not to repeat normative language
(paraphrased or not) from the POSIX standard.

So glibc should be tested to verify the behavior it actually exhibits,
and the language above then updated to describe that, noting any
deviation from POSIX's prescription.

The same can, optionally, be done for other libcs like musl.

Alex, please correct me if I'm mistaken.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2] abort: clarify consequences of calling abort

[Tomáš Golembiovský]

Hi,

On Mon, Jul 10, 2023 at 10:21:50AM -0500, G. Branden Robinson wrote:
> Hi Tomáš,
> 
> At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
> [...]
> > Clarify the status reported by wait*() functions. The requirement
> > comes from POSIX specification.
> [...]
> > +The status made available to
> > +.BR wait "(2), " waitid "(2), or " waitpid (2)
> > +by
> > +.BR abort ()
> > +shall be that of a process terminated by the
> > +.BR SIGABRT
> > +signal.
> [...]
> 
> I believe Alex's preference in the Linux man-pages project is to
> document what is actually implemented, not to repeat normative language
> (paraphrased or not) from the POSIX standard.

Yeah, I don't feel strong about it and I have my doubts if mentioning is
useful anyway. It should be obvious from the fact that abort() raises
SIABGRT. I will drop that sentence. 

> 
> So glibc should be tested to verify the behavior it actually exhibits,
> and the language above then updated to describe that, noting any
> deviation from POSIX's prescription.

As a side note, in the normal situation glibc does what it should.
However, in the unlikely situation that raise() fails unexpectedly,
abort() tries to terminate the process with other means or loops for
ever if everything else fails to satisfy the condition that abort()
should never return.

    Tomas

> 
> The same can, optionally, be done for other libcs like musl.
> 
> Alex, please correct me if I'm mistaken.
> 
> Regards,
> Branden

Re: [PATCH v2] abort: clarify consequences of calling abort

[Stefan Puiu]

Hi,

On Mon, Jul 10, 2023 at 6:41 PM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
>
>
> At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
>
> I believe Alex's preference in the Linux man-pages project is to
> document what is actually implemented, not to repeat normative language
> (paraphrased or not) from the POSIX standard.
>
> So glibc should be tested to verify the behavior it actually exhibits,
> and the language above then updated to describe that, noting any
> deviation from POSIX's prescription.

At least when Michael Kerrisk was the man-pages maintainer, he would
usually ask for a test program proving that the documentation change
is correct and / or a pointer to the kernel / libc code, where the
behavior could be (hopefully) inferred. I think this is valuable, it
makes it easier to track why a certain change was made, and how the
behavior was observed at that time. If running the same test case
after X years yields a different behavior, it's clear the change that
it triggered no longer stands. It's also fair, I think: the burden of
proof is on the person suggesting the change.

Just my 2 cents,
Stefan.

>
> The same can, optionally, be done for other libcs like musl.
>
> Alex, please correct me if I'm mistaken.
>
> Regards,
> Branden

Re: [PATCH v2] abort: clarify consequences of calling abort

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1734 bytes --]

On 2023-07-12 12:45, Stefan Puiu wrote:
> Hi,
> 
> On Mon, Jul 10, 2023 at 6:41 PM G. Branden Robinson
> <g.branden.robinson@gmail.com> wrote:
>>
>>
>> At 2023-07-10T15:59:28+0200, Tomáš Golembiovský wrote:
>>
>> I believe Alex's preference in the Linux man-pages project is to
>> document what is actually implemented, not to repeat normative language
>> (paraphrased or not) from the POSIX standard.
>>
>> So glibc should be tested to verify the behavior it actually exhibits,
>> and the language above then updated to describe that, noting any
>> deviation from POSIX's prescription.
> 
> At least when Michael Kerrisk was the man-pages maintainer, he would
> usually ask for a test program proving that the documentation change
> is correct and / or a pointer to the kernel / libc code, where the
> behavior could be (hopefully) inferred. I think this is valuable, it
> makes it easier to track why a certain change was made, and how the
> behavior was observed at that time. If running the same test case
> after X years yields a different behavior, it's clear the change that
> it triggered no longer stands. It's also fair, I think: the burden of
> proof is on the person suggesting the change.

Hi Stefan!

Thanks for pointing that out!  I can only agree with you, and
I try maintain that good tradition of Michael.

Cheers,
Alex

> 
> Just my 2 cents,
> Stefan.
> 
>>
>> The same can, optionally, be done for other libcs like musl.
>>
>> Alex, please correct me if I'm mistaken.

Hi Branden!

I won't correct you either ;)

Thanks!

>>
>> Regards,
>> Branden

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]