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 13:53:14 +0000 Message-ID: <87o70tz3an.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> <87zfkdz6kl.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="30677"; 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:25:36 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 1tSGi7-0007q5-NG for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 15:25:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSGhl-0008AK-6w; Mon, 30 Dec 2024 09:25:13 -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 1tSGCy-0008Rr-3B for emacs-devel@gnu.org; Mon, 30 Dec 2024 08:53:24 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSGCv-0006Pt-O8 for emacs-devel@gnu.org; Mon, 30 Dec 2024 08:53:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735566798; x=1735825998; bh=s0pcRF4HhNVKOj3Oa1McIuVGX+uVgWZcqlFLh7lm1BQ=; 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=ENxKyAO5nn4szjTz0QS15pzilf+RB6giuWayeaN8lE5921YWiIwlZdihOtlobUJed IfmrUgiLsIxrRkQgc2xYDihPb79Qvy0eEPb9YpN+jI9JtTJ/Isr24HKZV3g+MT+9hN wVhSKysIHdZv6s1btTliQpl9EC9XWGoBPLE4EgyN9VlwOpT5pu9T+AlTl1ZUaUHu3D 2YV1A6zsxxYvor9VPjgHts+uyuoYJjVSYNPAZk5kPqQSx3oeFQ2agwMQ2LuTcq5XYw wzRnkNLHs/Qy2vcrIehhiEM2sAbidq3MEBiWQ+gstqS8VhTQ0MAR7SCgcbVn8dRlDP dL9OHLU6In1iw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9b8856e7d9edb763ab3bea0f0c5671406617b185 Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.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_DNSWL_NONE=-0.0001, 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:25:06 -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:327430 Archived-At: Gerd M=C3=B6llmann writes: > Pip Cet writes: > >> Pip Cet writes: >> >>> "Helmut Eller" writes: >>>>> I find that difficult to understand. But it may be just a >>>>> statistical phenomenon. Maybe filling up an APs memory is so fast so >>>>> that the probability of a signal hitting while owning the mutex is cl= ose >>>>> to zero, or something. >>>> >>>> Very few of Emacs' signal handlers actually touch a barrier. I've als= o >>> >>> Indeed. These crashes are rare in typical usage, which doesn't mean we >>> should delay fixing them until Emacs is "unstable enough". It already >>> is, IMHO, because we take that approach too frequently. >>> >>>> not seen any reproducable receipes for the "signal issues" that the ig= c >>>> branch supposedly has. >>> >>> Removing the SIGPROF protection code should allow Ihor's recipe to cras= h >>> again. >> >> Confirmed. Here's the recipe (which, yes, you have already seen): >> >> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00560.html >> >> Make igc_busy_p () return false (as we could do if the "supposed" signal >> issue weren't real), immediate crash. >> >> Pip > > With > > modified src/profiler.c > @@ -347,7 +347,7 @@ record_backtrace (struct profiler_log *plog, EMACS_= 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? 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