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:01:49 +0000 Message-ID: <87h6d97zzm.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25826"; 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:01:09 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 1sOLKu-0006UG-Sa for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 20:01:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOLK8-0006vH-G3; Mon, 01 Jul 2024 14:00:22 -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 1sOLK6-0006v7-8H for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:00:19 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOLK3-0007tg-6j for emacs-devel@gnu.org; Mon, 01 Jul 2024 14:00:17 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 25FF3240104 for ; Mon, 1 Jul 2024 20:00:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719856812; bh=DRKlDCP+WNY0U7tj3djf4HMGXnfoPm8MgcUmlnLD/aY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=eYNrapjKK9huNOlfPkJtIIGqVc7f46cBpgx426vE2CkO+/35sSDnOWNRom0xhUkQ/ YkRjRHjFto4huqvYrkxO4fbpK+z2Aj0kj1tSGKPJzYVsMsZrUwUpsuEFQpoAPFaaq/ BPm7rWCnH3GWNN2CHDlDmGaZif7u/mz70nejEO0zD93BqX2OwqURy75MSgp5W1E7Ml hGxJ8aKRvvlfYIvXV3OKFblX4mQMUciyQj/LGgdW204UgTqzu0biuPaMnfkbhZXpHu LXw+T3P9RXipVhhNekDDocNMTxee5Y28s7xYq0eG10E/1QtoYo7z53RW0aCmBGDsF+ kCrupkA69PH0w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WCYjR3gSCz6txb; Mon, 1 Jul 2024 20:00:11 +0200 (CEST) In-Reply-To: <86le2ldn2t.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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=ham 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:321044 Archived-At: Eli Zaretskii writes: >> 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? Nope. AFAIU, the problem we are facing is not when MPS GC runs, but when we query MPS to allocate memory in the managed arena. > 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. I do not mean calling malloc. I mean, what happens if a signal arrives _while_ malloc is still in the process of allocating data? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at