From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14333 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Conditional signal safety? Date: Mon, 1 Jul 2019 12:13:16 -0400 Message-ID: <20190701161316.GU1506@brightrain.aerifal.cx> References: <20190629055405.GA22788@voyager> <87imsmidvs.fsf@oldenburg2.str.redhat.com> <20190701140631.GP1506@brightrain.aerifal.cx> <87h885bvhg.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="32221"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14349-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 18:13:31 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhyvq-0008Fs-MM for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 18:13:30 +0200 Original-Received: (qmail 29989 invoked by uid 550); 1 Jul 2019 16:13:28 -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 29971 invoked from network); 1 Jul 2019 16:13:28 -0000 Content-Disposition: inline In-Reply-To: <87h885bvhg.fsf@oldenburg2.str.redhat.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14333 Archived-At: On Mon, Jul 01, 2019 at 05:55:07PM +0200, Florian Weimer wrote: > * Rich Felker: > > > On Mon, Jul 01, 2019 at 06:21:11AM +0200, Florian Weimer wrote: > >> * Markus Wichmann: > >> > >> > at work yesterday I had to build an exception handler (a signal handler > >> > for SIGSEGV, SIGBUS, SIGILL, and SIGFPE). For my purposes, it was really > >> > convenient to just use dladdr() to find out at least what module and > >> > function PC and LR were pointing to when the exception happened, so I > >> > used that function. > >> > >> Are these signals generated synchronously, by running code? Then the > >> rules regarding asynchronous signal safety do not apply. > > > > That's a meaningful distinction if they're generated by accesses in > > the application code. If they're generated by accesses from within > > standard library functions (e.g. because you passed an invalid pointer > > or one to memory that was intentionally setup to generate them) to a > > stdlib function, it's just UB, and if you were going to define it, > > it'd still be an async signal context just because it's async with > > respect to the interrupted state of the stdlib function being > > unspecified/unspecifiable. > > Right, but if libc code traps without violating preconditions, that's > generally a bug. Yes. If any of these signals are generated in libc without the preconditions of the interface having been violated, that's a bug in libc. For appropriate notions of what the preconditions are. It's clear for stuff like invalid pointers, but less obvious when you're dealing with things like memory setup explicitly to trap. My view is that such memory still does not constitute the regular C object the function requires, and thus the standard doesn't define any behavior for it. I think it would be hard to specify any particular behavior without also specifying a lot of the library internals -- either you have to specify that the signal context is an async one, or you have to place constraints on how internal locking and resource usage works and what locks can possibly be held by what interfaces. So, IMO you have to treat it as "at best an async signal context; at worst, UB and thereby completely undefined program state". > And if you violate preconditions, than *that* already > triggers undefined behavior, and not the trap later on. (For example, > the compiler uses the knowledge of well-known functions and optimizes > accordingly.) Yes. Rich