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 21:08:23 +0300 Message-ID: <86h6d9dlyg.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> <86le2mhhsj.fsf@gnu.org> <875xtqramd.fsf@gmail.com> <86cynyhfsn.fsf@gnu.org> <87v81qp91g.fsf@gmail.com> <86r0cefb0i.fsf@gnu.org> <86msn1fk0c.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33142"; 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 20:09:21 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 1sOLSq-0008O5-I0 for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 20:09:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOLS2-00008W-LH; Mon, 01 Jul 2024 14:08:30 -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 1sOLS1-00006y-KB for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:08:29 -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 1sOLS0-0002ja-Jy; Mon, 01 Jul 2024 14:08:28 -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=vSxdodG0BDDVsleiLkLVuGV2GvAN3b3ypXTQUz01Vok=; b=PKKUf+6xdXOp 6qTmL/9xmXP1dHaeLnbmq2uNYpcgUX4phnLr4AcVk++NtuUfGI/9vkMGsggmwEE1wK+dWNj5f+p8l mJuPyE0TkRzLVt9jqK7L4kOSoY0kAxoAQdM4WDF5uBnR1syi8XiDX7xzezej+Sn5fkK1jxh5QpwXx VUmDbEkgMhMr2tUzfQoU+cpNlVO3jmLjOhk6nmq8AS9+GI1l6o/9e7tXT7Au41R1ewhiU8jTP6xL6 mvjwkc6qkm49mfyR3niRehFLEJweHF0YxV3s+cADVZlfw6hxHbJjNgGcIe48zkhyNomrtQQFB2aIR fNsfBhj7VRlV3CBFvcviSQ==; In-Reply-To: (message from Pip Cet on Mon, 01 Jul 2024 17:27:49 +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:321045 Archived-At: > Date: Mon, 01 Jul 2024 17:27:49 +0000 > From: Pip Cet > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, yantar92@posteo.net, emacs-devel@gnu.org > > > It goes without saying that updating a static data structure makes the > > signal handler non-reentrant, and it should at least block SIGCHLD. > > Blocking SIGCHLD in a SIGCHLD handler is redundant unless SA_NODEFER is in use. Are we talking about a different handler here? First, that queue was intended for more than just SIGCHLD. And second, depending on the OS, nested signals can or cannot be possible, so we need to take that into consideration. > One last suggestion: how about blocking those signals for most of Emacs' lifetime, only unblocking them in maybe_quit or at similar points? That would allow us to keep the existing signal handlers and make them safe... IMO, this would be the opposite of what we should do. We should have these signals blocked for as little time as possible, because otherwise the features built on them will be much less useful. For example, SIGUSR1/2 are a means of forcing Emacs out of some infinite loop which is otherwise uninterruptible -- if we let these signals be unblocked only in maybe_quit, we will have lost this useful feature. Which is why I suggested to block the signals before calling MPS and unblock them immediately when we return from an MPS call. All of these calls are in igc.c, so the job of adding these blocks, while mundane and boring, is not impossible. But if people who have time to work on that disagree, I have no means of making them do what they don't agree with. > I still think this is a simple oversight on the part of MPS, FWIW. You shouldn't allow other signals when handling SIGSEGV, or at least give the client program an option to specify a signal mask. That's not the problem, AFAIU. The problem is that a signal handler which accesses Lisp data or the state of the Lisp machine could trigger an MPS call, which will try taking the arena lock, and that cannot be nested, by MPS design. And our handlers do access the Lisp machine, albeit cautiously and as little as necessary. So when the signal happens in the middle of an MPS call which already took the arena lock, we cannot safely access our data.