From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: a random backtrace while toying with gdb Date: Mon, 01 Jul 2024 14:07:31 +0300 Message-ID: <86msn1fk0c.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <87wmm6rcv1.fsf@gmail.com> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86r0cefb0i.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11760"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 13:09:12 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sOEuE-0002oS-9t for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 13:09:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOEsq-000421-84; Mon, 01 Jul 2024 07:07:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOEsn-0003sj-Ta for emacs-devel@gnu.org; Mon, 01 Jul 2024 07:07:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOEsm-0006B4-IH; Mon, 01 Jul 2024 07:07:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=SImg5CV9d5z3iCtVSs4o0Q9K1BwBR1sG/c7ycpIaTY0=; b=JjvO8+szbAYR i/ooD2R292VnHKE8dP1/yc096G8v9bG/n8sBILdYN7Pk9UoqtA0CcKLJCG2QSisLN+L60FHrAemP2 M/pBJKDWnGcovHyZHfs0Io1Mf9ojVToR7aCVib9p3WZj+XP2mxewFQWpNn2B9iCcve4zZ8zmffW6a u9//QPpyGyI2TpxiZdHN6lPbWNZZ2A2y7PKeQtRJBo8XEvLRIWALcEdLBuqjPJCVglDr9xsSrtfRB elmUztr2rVmHxf3L+JmTz/Rf2he6MQ2/QFrmIH0U/vq9ET73HNMAOWI4UaPjw211Hy2aCdcYLKCMc yWCwZ2qQ8s21QwUEywCb9Q==; In-Reply-To: (message from Pip Cet on Sun, 30 Jun 2024 20:32:54 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321006 Archived-At: > Date: Sun, 30 Jun 2024 20:32:54 +0000 > From: Pip Cet > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org > > On Sunday, June 30th, 2024 at 20:09, Eli Zaretskii wrote: > > > Date: Sun, 30 Jun 2024 19:25:36 +0000 > > > > > From: Pip Cet pipcet@protonmail.com > > > Cc: Eli Zaretskii eliz@gnu.org, gerd.moellmann@gmail.com, yantar92@posteo.net, > > > emacs-devel@gnu.org > > > > > > IIUC the consensus is you can set an "int" or "bool" to true, or write to a self-pipe, but that's about as much as you should ever do in a signal handler... > > > > That's not true, AFAIU: you can safely call any of the dozens of > > functions listed by the signal-safety(7) man page. > > I think the implication is reversed there: functions that aren't on that man page definitely aren't safe to call, but that doesn't mean that any old C code modifying complicated structures using only the listed functions is safe, at all. I didn't say "any code"; obviously, one can write unsafe code even without calling any function! This is a strawman if ever there was one. That man page is very clear: An async-signal-safe function is one that can be safely called from within a signal handler. Many functions are not async- signal-safe. In particular, nonreentrant functions are generally unsafe to call from a signal handler. [...] To avoid problems with unsafe functions, there are two possible choices: (a) Ensure that (1) the signal handler calls only async-signal- safe functions, and (2) the signal handler itself is reentrant with respect to global variables in the main program. (b) Block signal delivery in the main program when calling functions that are unsafe or operating on global data that is also accessed by the signal handler. Generally, the second choice is difficult in programs of any complexity, so the first choice is taken. [...] The set of functions required to be async-signal-safe by POSIX.1 is shown in the following table. The functions not otherwise noted were required to be async-signal-safe in POSIX.1-2001; the table details changes in the subsequent standards. Function Notes abort(3) Added in POSIX.1-2001 TC1 accept(2) access(2) [...] > My point is that complicated C structures, such as the queue Helmut implemented, cannot usually be safely modified from signal handlers unless the non-signal code takes care to block signals while it is modifying the structure. It goes without saying that updating a static data structure makes the signal handler non-reentrant, and it should at least block SIGCHLD. > All that said, it's not like our existing code looks safe, either, so the patch is definitely an improvement! I don't think I agree with the "improvement" part. The challenge is to prevent crashes without giving up useful features, not by means of giving them up.