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 20:44:10 +0300 Message-ID: <86le2ldn2t.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> <86tthafbix.fsf@gnu.org> <87plry6sv3.fsf@localhost> <86le2lfjqv.fsf@gnu.org> <87jzi5ibbe.fsf@localhost> <864j99fg0a.fsf@gnu.org> <87msn18225.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21862"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 19:45:26 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 1sOL5h-0005S3-Up for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 19:45:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOL4r-0001VA-WC; Mon, 01 Jul 2024 13:44:34 -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 1sOL4l-0001UK-70 for emacs-devel@gnu.org; Mon, 01 Jul 2024 13:44:30 -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 1sOL4X-0000Ks-3M; Mon, 01 Jul 2024 13:44:22 -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=KEZMUhBFCQoi8suHnJkzQ/2QfcTzZJmuvc598naqkss=; b=nFXcFfmWkcyh x9qRpcMI3bKUHccosENvwvwKGUznrw49se30idpekaGcKqXO/hdFq1eKO9UMuzEZHBDWzfoX07dbz JvrN7B3VlkstLor+BhfNzq3NwPLv1iydXUxmd+hpJUXkEMAjQVSK9/One3eUnCP+Ddajf07ukxrd6 OUSZ8eTs+HSm6jb07M2w1nBmn9r0q6Jxe9E/D90LNYkWsLXzCAEOsZEC4+xDGm6YEGV4aMbaFHQF/ 2tnugu8FqiydLRA7DL+X3xKAwRl3nuKStdDFbRqiKHN7sLJnZh9D8a/KrpF7EdgrpmHieB01D2AEn LmmtRy2mwhaeMDvD/noRnw==; In-Reply-To: <87msn18225.fsf@localhost> (message from Ihor Radchenko on Mon, 01 Jul 2024 17:17:06 +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:321043 Archived-At: > From: Ihor Radchenko > Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, > emacs-devel@gnu.org > Date: Mon, 01 Jul 2024 17:17:06 +0000 > > I looked a bit into mps sources and what I observe is > mps_ap_fill -> ArenaEnter -> ArenaEnterLock -> LockClaim. > This is active for the duration of our dflt_scan. > Nothing can access the MPS arena and when something tries to, we get > assertion failure. Yes. > It looks like we can test whether the Arena is locked via > > /* mps_arena_busy -- is the arena part way through an operation? */ > > mps_bool_t mps_arena_busy(mps_arena_t arena) > > Although it does not help with the underlying problem with signal > arriving while we are in the process of allocating a new object in the > pool. Blocking signals whose handlers access the data of the Lisp machine will prevent that. > I am wondering what happens in the same situation when using normal > malloc. (Or may it never happen when using normal malloc?) You mean, when the current GC runs? Signal handlers are free to access Lisp data even if the signal happens while we are in GC, they just need to be careful to mask off the mark bit (see, for example, the commentary to handle_child_signal). If you really mean malloc, then there usually is not problem because signal handlers cannot safely call malloc. And if malloc causes GC, see above.