From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 14:32:07 +0000 Message-ID: <87jzbhz1ht.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> <87zfkdz6kl.fsf@protonmail.com> <87o70tz3an.fsf@protonmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6748"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Helmut Eller , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org To: =?utf-8?Q?Gerd_M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 15:50:34 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 1tSH6I-0001am-MD for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 15:50:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSH5d-0005tT-Vb; Mon, 30 Dec 2024 09:49:53 -0500 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 1tSGoc-0002u8-9G for emacs-devel@gnu.org; Mon, 30 Dec 2024 09:32:18 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSGoa-0003T9-CI; Mon, 30 Dec 2024 09:32:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735569132; x=1735828332; bh=l9ZmYoFaTpH7Rncw5cVWzDnntt6MtT/M6+wva4375Gs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pLDn5Jx1McibiBiRQ5tL9Dy5CnZfQQY7KLWPZ1D9/qGNZkHzAoxzk5kYdj4vtztHg cAP0+63XM0LNKvcCsHitSBeBunpwbbltQRRPPHUTORLvy6WwX3OUxyn63+AwwNqGtt cFOkUx2ikWEDqe31xAZGp1eZQa10zGrCwMk5tf9rIUMewjFyYmw95SRnjLH3rwMWqV uKC7lfNoD7FEJ5GN556J/0Ebow1gmtVWO4CJYOfME6kl1TLw88wQQluxIZZaXVOdXN KKPMbgfqFRB1HozjYdGuQYHtngIgliZvlxDqLzfRUclqZBNg5ao/f7Ucqpquz9ipMH 4vxTuuvop2Zcw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a042187c3f83d55cb34d77f98936f8e40b39ea3b Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 09:49:52 -0500 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:327431 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > >>> With >>> >>> modified src/profiler.c >>> @@ -347,7 +347,7 @@ record_backtrace (struct profiler_log *plog, EMAC= S_INT count) >>> add_sample (struct profiler_log *plog, EMACS_INT count) >>> { >>> #ifdef HAVE_MPS >>> - if (igc_busy_p ()) >>> + if (false) >>> #else >>> if (EQ (backtrace_top_function (), QAutomatic_GC)) /* bug#60237 */ >>> #endif >> >> This is after removing gc_signal_handler_can_run, right? > > Right. And meanwhile it also survived the same parsing 100 times in a > loop with profiling on around it. Yes, without the SIGSEGV-alloc-SIGSEGV case, it becomes less likely to hit a memory barrier. But the alloc-SIGPROF-SIGSEGV case is real, we've seen backtraces for it. >> Even if, in addition, I block signals in the SIGSEGV handler, I see >> crashes here, FWIW, but not quite every time that recipe is run. It >> seems to work even less reliably when rr is in use (and then I realized >> I was running an optimized build so the trace was useless, sigh). >> >> I'd still like to see at least one crash on macOS, but there's nothing >> I'm aware of that would prevent such crashes, only make them (maybe >> much) less likely. For starters, fewer pages so fewer barriers :-) >> >> Pip > > Me too, but I agree with you. It should eventually freeze, there's > nothing preventing it that I could point to. Or produce invalid data, which seems more likely: if we're scanning the segment, the memory barrier won't be in place, but the contents will be invalid, pointing to objects which we already decided to move (IOW, if my double-mapping idea were in place, it'd be easier to catch these bugs). A crash is better than derefing random pointers pointing to the (new) young generation when the object has been moved. (I'm running into separate rr bugs on both systems I'm testing this on, so we'll just have to assume that's what behind those crashes, at least sometimes). Does adding mps_message_poll (global_igc->arena) in the signal handler produce a crash/deadlock for you? Last thing I'm asking you to try today, I promise :-) Pip