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: Sun, 30 Jun 2024 07:55:44 +0300 Message-ID: <867ce7hvvz.fsf@gnu.org> References: <87bk3jh8bt.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?iso-8859-1?Q?M=F6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 30 06:56:45 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 1sNmcE-00067w-Uh for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jun 2024 06:56:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNmbR-00057Y-Qs; Sun, 30 Jun 2024 00:55:53 -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 1sNmbO-00057P-WC for emacs-devel@gnu.org; Sun, 30 Jun 2024 00:55:51 -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 1sNmbN-0000Tf-5m; Sun, 30 Jun 2024 00:55:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=sq8SHG2vw4pHkmc2HV8B/X66xgQ4XL/cMXAv34YLBao=; b=Vqa777cnAtxEKxtT7haY zS4VgcZMnZDilHX9AzbXCAiUMA/xJrBgwiXKPBrZ7AuQVJen8Uy+6nwJxJS/l/+zBl+xIQ/LxsJEu /6VdYJdriPO4UeIQy6epM/AjsbuMjBjDwU24iYhfTftixH9nRVUV6MSZ9Htay4s3esIoAafdAsGuh VCyP9Xg0cKCDIJvKS60WU09PRkcEJxY4uyFZ32ZczLW5h9MZ8m0Xp2HDeCsieC57+WHKzBI3/bxhB Shsx8lRXDXOqA9aInadXyyhblqMMcozJcObW/rMpKWFiA5b/1QPdlsmwoYgk6ME+jdmjRdO+4z6CM Oqce/upGL/EooA==; In-Reply-To: (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Sat, 29 Jun 2024 23:46:27 +0200) 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:320908 Archived-At: > From: Gerd Möllmann > Cc: Ihor Radchenko , emacs-devel@gnu.org, Eli > Zaretskii , eller.helmut@gmail.com > Date: Sat, 29 Jun 2024 23:46:27 +0200 > > Pip Cet writes: > > > On Saturday, June 29th, 2024 at 19:11, Ihor Radchenko wrote: > >> I just got this while starting up Emacs on the latest scratch/igc (with > >> native-comp). > > > > Looks like the same double-signal situation we saw with the profiler, only this time it's SIGCHLD interrupting an MPS scan. > > > > Pip > > Indeed > > #10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) at /home/yantar92/Git/emacs/src/lisp.h:1105 > #11 PROCESSP (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:212 > #12 XPROCESS (a=XIL(0x7fffeb90875d)) at /home/yantar92/Git/emacs/src/process.h:224 > #13 handle_child_signal (sig=sig@entry=17) at process.c:7660 > > Someone has an idea what to do with that? Call sigblock at the beginning of dflt_scan (and friends) and sigunblock before it returns? Are there any guidance in the MPS docs for handling such signals in these situations? If not, can we ask them for guidance? It is unrealistic to expect any real-life program to do nothing in signal handlers except setting flags. And even flags could be subject to MPS moving GC, at least in some cases. So there must be some way of dealing with that in a safe way. > And maybe how to reproduce? Run for enough time with subprocesses that start and terminate, I guess?