From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: MPS: a random backtrace while toying with gdb Date: Mon, 01 Jul 2024 18:51:13 +0000 Message-ID: <87a5j17xpa.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24661"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 01 20:50:37 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 1sOM6m-0006DK-Pm for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 20:50:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOM5x-0007zH-H7; Mon, 01 Jul 2024 14:49:45 -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 1sOM5v-0007yr-Gg for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:49:43 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOM5t-0002w3-Ti for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:49:43 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BF3B3240027 for ; Mon, 1 Jul 2024 20:49:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719859778; bh=tPwh8/mk2D7MR2EPgtIgixCxC01pFdfPJ4j2bnEFLBQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=BOrrdK36NYs9qOwk0Gk8t0WDXRdDQ426CAtJr7ZYiGE5BarlagJoIXdwIK3rtD4zM shfRNyjNbaPc+GfoP7Wxnrv2bL3iaWm/zvaSCGOc2fQiAgJbTFwQ/GhBcUC2qrw67I k9Tx/k80N4gvYJiMxRd41bRKq5ASfuVS4ptgPKEyyCGgA4o9n/+wbIX77JFreY5+W3 YsJnB18rf0JEGw+d2kakfj4xSgDQKkpEMwtsASrCDLvaAVLaaHAFy1/JEWWcBPfYTY CSSgy2G3sD8AIxHVMo4HmnCAzdIUF0Gy+OxFtL9O9cAOWQUfm10pQ5pSH9bEvt2RHJ e6pDfJq7IISSQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WCZpT01R6z6tsf; Mon, 1 Jul 2024 20:49:35 +0200 (CEST) In-Reply-To: <86bk3hdkv5.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:321055 Archived-At: 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_. Fcons requests MPS to allocate memory for a new cons, MPS does it, not super quickly, and blocks the whole arena (all the lisp memory) in the process. At the same time, signal arrives, and we try to access the (blocked) arena. 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). I do not see why the same cannot happen with vanilla malloc, unless, of course, it blocks memory much more granularly, guaranteeing that live objects are always reachable. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at