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 signals and Emacs (was: STatus of MPS branch) Date: Mon, 22 Apr 2024 09:15:38 +0300 Message-ID: <86a5ll7wj9.fsf@gnu.org> References: <878r16n5jl.fsf@gmail.com> <87ttjulb16.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26910"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 22 08:16:29 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 1rymyb-0006no-Gf for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Apr 2024 08:16:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rymxs-0002Yw-2R; Mon, 22 Apr 2024 02:15: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 1rymxr-0002YU-3G for emacs-devel@gnu.org; Mon, 22 Apr 2024 02:15:43 -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 1rymxp-0001Xr-Ri; Mon, 22 Apr 2024 02:15:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=wILakw9b8N0boEnmmPG1fLDjF9eqPxSbNUX9mtM+AlA=; b=DsIsVOTHa8q2klcgdt0U AJ99R7lIa6N9zWy2BZ0wJKl12C/fGoKnEIV0rveMzQ0SnRWQMBJdV29AO8xfmI/lNBLB5grBYSwj0 ksQld4Uga55lop3NC7oUmDlFC/pJkL11PxxGFUWZbWJTIueg2qqVTNE5DV4o5Jd4PnEdc+3XNDeM7 Hl17j2wyuqF0yTkrtN98avVJEbxLX6ID3ioZv3/9Ag16XZeEDTs91GtUpwyECbDuTxwOslPxZEOeA kF5tSJrEiNQg+/Yd8v4C5RhkKL1Lh6PtJfvjoUJO9FnvGPqgo734b853sz2xufJLN3Hl/eSYM84kV HxDO6mY/MUnlpg==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 22 Apr 2024 07:28:40 +0200) 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:317950 Archived-At: > From: Gerd Möllmann > Cc: emacs-devel > Date: Mon, 22 Apr 2024 07:28:40 +0200 > > Helmut Eller writes: > > > I changed some things and now I can no longer reproduce the exact same > > problem. But it looked to me like a perfectly normal string with > > intervals=0x0. Strangely, accessing the intervals field from GDB didn't > > cause any SIGSEGV. > > > > However, after setting breakpoints in handle_sigsegv and sigHandle (from > > MPS) I discovered that sigHandle wasn't called. So my hypothesis is > > that the signal handler isn't initialized properly. In particular, it > > seems problematic that ProtSetup (from MPS) is called before > > init_signals. > > > > Then I moved the call to init_signals in emacs.c up before the call to > > init_igc and voilà: the build completed. With an apparently working > > (tty-only) Emacs. > > Oh, I have an idea! Hopefully I can explain it. Let me try... > > MPS is a copying GC, and it uses read-barriers for object forwarding. > > Let's say O is an object managed by MPS, and it decides during GC that O > shall be moved in memory to the new location N. This is done by copying > O to N, storing at O the information that it has moved to N, and putting > a read-barrier on O. > > The last step means that any access to O by the client (Emacs) leads to > MPS being involved, which updates the reference to O to a reference to > N. > > Plus... > > MacOS has a kernel that is, let's not get into details, a conglomerate > of Mach and FreeBSD kernel. This means MPS can use Mach mechanisms for > implementing read/write barriers, and I know it does because I landed in > that code in LLDB at some point. > > Linux is not Mach, so MPS must use VM protection and signals. > > And finally, the idea now would be that MPS's signal handling (probably > SIGSEGV and SIGBUS) and Emacs' signal handling interfere with one > another. > > For example, MPS has done its thing and read-protected O from above. > Emacs accesses O, a SEGV is signaled, Emacs gets the signal and thinks > it's bit the dust. And so on. > > Or, IOW, we need some Emacs signal handling support personal. Paul, can you please help by suggesting how to handle this situation?