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 14:13:12 +0300 Message-ID: <86le2lfjqv.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38335"; 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 13:13: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 1sOEyg-0009jL-1h for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Jul 2024 13:13:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOEyK-0001xO-91; Mon, 01 Jul 2024 07:13:24 -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 1sOEyG-0001wq-8m for emacs-devel@gnu.org; Mon, 01 Jul 2024 07:13:20 -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 1sOEyF-0000Iy-7i; Mon, 01 Jul 2024 07:13:19 -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=MnNmvpf2zmRTCKmRTEk72LxEneyLDmgsAW30FBISGXc=; b=jVPfu2jzooOI vac1s15+nUj3lJZ7ngd5cWQPFJqPKM/We0EV92ki0ItZx14o2tANzfNDEIhwe7NvBjxcTtPrHKGN9 LqTYooommWBwvvzWrZ79WJLTayIcdm2a8k9pXyxG5XdQzaK+QMAjopNp5ME4z1ihkY9vOkgQBQCZE PiB514XwL3O3LwPcI6fLu53z/JHm02PLIWpIER3/vPFGhAVY7fR51OVYtzW2f3N7H3V68xGHegXIk F2wojAL2gP6hdMFKVmFYBgPVrK7XsnyuM5JaGax/tKlwyEKawV0BPQssJHBr1TRCBs6j4qy9KodVU FqicB6K9LELA8J79EQP9iQ==; In-Reply-To: <87plry6sv3.fsf@localhost> (message from Ihor Radchenko on Sun, 30 Jun 2024 21:08:48 +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:321008 Archived-At: > From: Ihor Radchenko > Cc: Helmut Eller , gerd.moellmann@gmail.com, > pipcet@protonmail.com, emacs-devel@gnu.org > Date: Sun, 30 Jun 2024 21:08:48 +0000 > > If my understanding is correct, the situation we have is when MPS is > performing root scan while also receiving another signal. During the > root scan, all other Emacs threads are suspended, and no state changes > are taking place - everything is locked by MPS thread, which is the only > thread running. > > Emacs signal handlers are, of course, installed for all the threads. And > since the only thread being running is MPS thread - it will be the one > handling the received signal. And the handler thus cannot run normally, > reaching out to the MPS-managed memory as usual. > > So, we should somehow arrange the handler to wait until the MPS scan > finishes and the actual Emacs threads are resumed. > Such waiting should not lose any information as the actual Emacs state > is not going to change during the scan. > > The simplest way to do it is setting up a mask for MPS > thread. (Although, we may or may not want to do it for profiler signals > specifically, depending on whether these signals will be queued by the OS > or merged into a single signal before unblocking - merging will make us > loose some samples) As I wrote earlier, these last crashes happened when the only thread running was the Emacs main thread, and MPS code was called from that thread, as side effect of allocating memory (AFAIU). So the situation with multiple threads is not what we see here. Nevertheless, please note that Emacs has machinery to deliver signals on the main thread, see deliver_process_signal (and be sure to read the commentary of that function). So if this is needed, we seem to already have the code in place to deal with it.