mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: abort() PID 1
Date: Mon, 4 Jul 2016 23:14:02 -0400	[thread overview]
Message-ID: <20160705031402.GT15995@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.LRH.2.20.1607041526500.30017@s1.palsenberg.com>

On Mon, Jul 04, 2016 at 03:30:23PM +0200, Igmar Palsenberg wrote:
> 
> 
> > > - the kernel will not deliver any signal to process 1, unless a signal
> > > handler for that particular signal has been installed
> > > 
> > 
> > not all signals behave that way.
> 
> For pid 1 this is the case. Unless some signals are exempt from this. 
> 
>  
> > > -if process 1 calls abort() (regardless of what purpose that would fill), then:
> > > 
> > >     - if a handler was setup, it should be done whatever the handler does
> > > 
> > >     - if a handler was not setup, nothing should happen (as in:
> > > process didn't receive any signal at all)
> > > 
> > 
> > this is raise(SIGABRT), abort is different.
> 
> Different how ? The manual says it's just a signal unblock followed by a 
> kill(self, SIGABRT).

The man page is likely wrong. Read the actual specification. It's
specified to raise SIGABRT as if by raise, but also to cause the
program to terminate with abnormal status in cases where raising the
signal does not cause termination already. And it's explicitly
forbidden from returning, ever.

> > > What the standards say:
> > > 
> > > (http://pubs.opengroup.org/onlinepubs/9699919799/)
> > > 
> > > "The SIGABRT signal shall be sent to the calling process as if by
> > > means of raise() with the argument SIGABRT."
> > > 
> > 
> > it also says
> > 
> >  "The abort() function shall cause abnormal process termination
> >   to occur, unless the signal SIGABRT is being caught and the
> >   signal handler does not return."
> > 
> > and
> > 
> >  "The abort() function shall not return."
> > 
> > (in c11 abort is _Noreturn and returning from such a function
> > is undefined behaviour).
> 
> Hmm.. What happens if a hander is installed, but that never returns ? (but 
> also doesn't terminate the process). If I read the manpage correct, it 
> says it's OK, but also says it isn't.

If the handler never returns then the program does not terminate from
the abort call. This could happen if the signal handler is exited
using longjmp/siglongjmp, or just by remaining in the signal-handling
context indefinitely, or by performing some other action to terminate
the process as part of the signal handler (e.g. _Exit).

Rich


      reply	other threads:[~2016-07-05  3:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04  8:09 Jorge Almeida
2016-07-04  8:28 ` Igmar Palsenberg
2016-07-04  9:37   ` Jorge Almeida
2016-07-04  9:31 ` Szabolcs Nagy
2016-07-04  9:49   ` Jorge Almeida
2016-07-04 13:30   ` Igmar Palsenberg
2016-07-05  3:14     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160705031402.GT15995@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).