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 make-thread Date: Sun, 23 Jun 2024 08:53:59 +0300 Message-ID: <864j9kfbm0.fsf@gnu.org> References: <87v823xvq1.fsf@localhost> <87msne3flr.fsf@gmail.com> <87frt63dvt.fsf@gmail.com> <86o77ulgk8.fsf@gnu.org> <87zfre1p3r.fsf@gmail.com> <87zfreo5u6.fsf@localhost> <87plsa1n8k.fsf@gmail.com> <87wmmio3vq.fsf@localhost> <87jzii1hbs.fsf_-_@gmail.com> <8734p61evv.fsf@gmail.com> <87cyoa3w5d.fsf@localhost> <87le2whkt2.fsf@localhost> <86sex4g53k.fsf@gnu.org> 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="39410"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 23 07:54:51 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 1sLGBe-0009zV-NV for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Jun 2024 07:54:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLGAv-0007yf-Ig; Sun, 23 Jun 2024 01:54:05 -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 1sLGAu-0007yW-Rf for emacs-devel@gnu.org; Sun, 23 Jun 2024 01:54:04 -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 1sLGAt-0002A4-8a; Sun, 23 Jun 2024 01:54:03 -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=zxBGyymHQhv0EJQIMcT3oTYWWx1MuIpQq6fvuLkboSY=; b=UZP57rRHqqjh8qhtBG+A rs54C2osaKkfe1wHLHEHWYaaUhRXQdbDCG9ll5DFUs54QJYpKkw/I/4ROMaE7FUi+bk/PhB2ugIpf +qlrNoRy+q8v9LbN4xVBkrE71DsT458WX4MCck04g40xNyX18rOc7YBn9hO0Ysnv2ftSlXVPq5p7+ avQCvxnVMJTqMzhZU+LeOR6LF6KlUvaQVWL0+DjdTcpMg9YXmN9dTnm9CKVDjLlC9x1cjbZhTzQom R3W4YpPnZ3p3RaoPEAHjG9/W3Yi5JQZ/veOxX6nu47tLX1FNUo1wnzK4e+R0usDVXklG5UYFfpq7p YyrqH2yYisuDvw==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 23 Jun 2024 05:18:06 +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:320497 Archived-At: > From: Gerd Möllmann > Cc: Ihor Radchenko , eller.helmut@gmail.com, > emacs-devel@gnu.org > Date: Sun, 23 Jun 2024 05:18:06 +0200 > > Eli Zaretskii writes: > > > ss.c:66: Emacs fatal error: assertion failed: warmest < stackCold > > AFAIR, MPS calls the bottom of a control stack "cold". Warmest could > then be the other end of the stack. And that's x86, so the stack grows > down to lower addresses, so that could make sense. Just guessing of course. > > > lockw3.c:98: Emacs fatal error: assertion failed: lock->claims == 0 > > And the typical followup crash from using MPS when it already has > crashed. > > > #27 StackScan (ss=0x1fc5fb70, stackCold=0x1edeff28, scan_area=0x2c11f9 , closure=0x0) at ss.c:66 > > #28 0x003c7494 in RootScan (ss=ss@entry=0x1fc5fb70, root=root@entry=0xa60e83c) at root.c:577 > > #29 0x003c7d1d in traceScanRootRes (ts=ts@entry=1, rank=rank@entry=0, arena=arena@entry=0x7100000, root=root@entry=0xa60e83c) at trace.c:528 > > #30 0x003c8118 in traceScanRoot (root=0xa60e83c, arena=0x7100000, rank=0, ts=1) at trace.c:545 > > No further clue from the backtrace. Is it safe to call igc--collect from a non-main Lisp thread? I don't understand well the semantics and the intent of what igc_collect does, so I cannot myself try to reason about this. Maybe what we do there is not safe when invoked from another Lisp thread? Do all our threads share the same arena, for example? If so, what happens when a Lisp thread is waiting for the global lock and another Lisp thread calls igc--collect? > > We must do something about these assertions: when there's an assertion > > violation caused by a thread which was started by MPS, we cannot call > > shut_down_emacs in that thread's context, for obvious reasons. We > > must instead set some flag which will cause the main thread or one of > > the other Lisp threads call shut_down_emacs. The MPS documentation > > says: > > > > Warning: The installed assertion handler must not call any > > function in MPS, and it must not access memory managed by the > > MPS. > > > > But our handler, igc_assert_fail, does exactly what they say not to > > do. > > I know. See the comment above that function. So how about not calling terminate_due_to_signal from igc_assert_fail? > One idea might be to set aside a block of memory for use when we know > that MPS is unusable. Then, make alloc_impl allocate from that block, > and probably we must put MPS in postmortem state. Or maybe we can just > use malloc in alloc_impl. > > I think one should try something like that so that Emacs can do its > thing as usual in such cases. Can of course fail, and will certainly be > fiddly. I currently don't have the energy to do that. One idea would be to exit the non-main Lisp thread (because I think shutting down Emacs from there is not safe anyway), then shut down from the main thread.