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 22:05:14 +0300 Message-ID: <867ce5djbp.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> <86le2ldn2t.fsf@gnu.org> <87h6d97zzm.fsf@localhost> <86frstdlla.fsf@gnu.org> <87ed8d7yy3.fsf@localhost> <86bk3hdkv5.fsf@gnu.org> <87a5j17xpa.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26287"; 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 21:05:46 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 1sOMLS-0006X3-16 for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 21:05:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOML8-0004vZ-1Q; Mon, 01 Jul 2024 15:05:26 -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 1sOML3-0004t4-BU for emacs-devel@gnu.org; Mon, 01 Jul 2024 15:05:22 -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 1sOML0-00026k-Ew; Mon, 01 Jul 2024 15:05:20 -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=OBF7YyxBOI7Kwaf3P52/ceIhX1MwVI+2RotVex29I6E=; b=rNiEJmtYevXY wtLyKKRQxUXm9G7YtGAv2RWpGQgtmOVJrGVu5O45AtRVPsutt+XWDAjxTs90Nspv0/SSfIHorzk9I L/0g0CAGEqb5+wOAbwLLo42afhNJnGUCl4dL4ithhHT4utb4OPoJtW1Q2d6W6nRNkeYZL1Guz9r7+ +fTDV8ZznnM1jz0na/OBlD9NLxfchZSeKKaQm5c1V/9zQlVctHCYXQ1qdqlsEyork3c6YbSmWYgAl nKompchUFSh+NSDheE+68ahU+P8e4xljm1yEbOPyLkZ36OVPg+nxGxj7RIvOBfYIeoAosu4UWDg1R Cm7O/0/p1LjifkJy56fOMQ==; In-Reply-To: <87a5j17xpa.fsf@localhost> (message from Ihor Radchenko on Mon, 01 Jul 2024 18:51:13 +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:321058 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 18:51:13 +0000 > > Eli Zaretskii writes: > > >> I was mostly asking about technical implementation details of how malloc > >> is preventing signals from being handled while it is doing its > >> job. > > > > It doesn't. It's the responsibility of the signal handlers not to > > re-enter malloc. > > > > We cannot do the same with MPS, because MPS can kick in outside of our > > control -- for example, if accessing some Lisp object hits the > > barrier. So we have no idea when MPS will take the arena lock, and > > this cannot prevent recursive locks, except by preventing our code > > which touches Lisp data from running when MPS is active because we > > called it. > > AFAIU, the situation discussed in this thread is different - MPS kicks > in _in our control_. Yes. But we had other backtraces where what I described happened. So the situation we need to solve is more general. > Note that our SIGCHLD signal handler itself does not re-enter malloc > (igc_malloc in our case). It just tries to access the memory arena that > is in transient state (in process of allocation). Yes. And any other signal handler that does something except raising a flag will do something similar. > I do not see why the same cannot happen with vanilla malloc Because vanilla malloc doesn't move objects in memory, and this doesn't need to lock the arena. It only needs to lock the data structure it itself uses for managing the memory, so if the handler doesn't re-enter malloc, it will never cause any trouble to vanilla malloc.