From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10293 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() PID 1 Date: Mon, 4 Jul 2016 23:14:02 -0400 Message-ID: <20160705031402.GT15995@brightrain.aerifal.cx> References: <20160704093140.GH19691@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1467688460 32071 80.91.229.3 (5 Jul 2016 03:14:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jul 2016 03:14:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10306-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 05 05:14:19 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bKGoU-0005u7-7n for gllmg-musl@m.gmane.org; Tue, 05 Jul 2016 05:14:18 +0200 Original-Received: (qmail 1641 invoked by uid 550); 5 Jul 2016 03:14:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1622 invoked from network); 5 Jul 2016 03:14:15 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10293 Archived-At: 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