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: profiler Date: Fri, 21 Jun 2024 13:43:14 +0300 Message-ID: <86plsalgot.fsf@gnu.org> References: <87v823xvq1.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8564"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, emacs-devel@gnu.org, gerd.moellmann@gmail.com, eller.helmut@gmail.com To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 21 12:44: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 1sKbkW-00022M-Bx for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Jun 2024 12:44:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sKbjj-0005iG-QE; Fri, 21 Jun 2024 06:43:19 -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 1sKbjj-0005i3-14 for emacs-devel@gnu.org; Fri, 21 Jun 2024 06:43:19 -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 1sKbji-0003dz-Na; Fri, 21 Jun 2024 06:43:18 -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=QMYtaUtyM0hPSfXJ6n1dtFHvqbDY5K4xLq8XD9NXiRY=; b=VHdxJcEH7M7BdQO40ie3 spoN5YKcH14R99oUOhFBhOIOcqeItkPi7u6U//J7sXMCpNHaH9kTUk8Xe3U7gH4wGopAVilU7skE0 WYzV27cPWK1UiO3pYsYyxPpU9e75HlXlDCT7zy0M55S99HEVphcrgWlI30ZpPcb1WcMYxoaXwLVAt V9aAkKT6JCo1655FdIKJB3SexeeM+rbmUKBi1o9M+AYIamr5ulWV2C2cj/9w+5dmCunWZ28+8Zia8 fP1cDeyPZ9/EvJQ/rw0asMtVT0JQ2qK2WGX/ElSa46Dn1KbHByX1cfLtMS2EvTLLhV3udaQcP7R8A X+ARt/qKyoz4lA==; In-Reply-To: (message from Pip Cet on Fri, 21 Jun 2024 08:23:16 +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:320381 Archived-At: > Date: Fri, 21 Jun 2024 08:23:16 +0000 > From: Pip Cet > Cc: emacs-devel@gnu.org, Gerd Möllmann , Eli Zaretskii , eller.helmut@gmail.com > > On Thursday, June 20th, 2024 at 19:24, Ihor Radchenko wrote: > > I am playing around with scratch/igc branch for fun, and there is one > > crash that I can reproduce quite consistently. > > > > All it takes is (1) compile Emacs without native-compilation support; > > (2) open Emacs; (3) M-x profiler-start; (4) run a complex operation. > > > > Steps to reproduce: > > > > 1. emacs -Q doc/misc/org.org > > 2. M-x profiler-start RET cpu RET > > 3. M-: (org-element-parse-buffer) RET > > > > Without step 2, no crash. > > Just sharing some information from a private discussion with Ihor: > > I can reproduce this locally. I can also "fix" it locally, but the problem seems more complicated since Ihor reports the fix isn't working for him. > > 1. MPS uses SIGSEGV internally, usually transparently to the client program. > > 2. The profiler uses SIGPROF, then runs complicated code in the handler. My understanding is it's carefully tuned not to trigger traditional GC, but it can and will cause (handled) SIGSEGV. > > 3. MPS isn't reentrant enough to handle a SIGSEGV while it's handling a SIGSEGV, and will die with one of a number of errors. This is not what happens in this case, so let's stick to what we actually see, okay? It's complex enough. > The right thing to do, IMHO, is to let MPS know that it should block SIGPROF (and any other signals that might use managed memory) while handling SIGSEGV. I disagree. MPS must be able to support programs compiled with "-gprof", so I don't believe SIGPROF should be blocked. The handler is our code, so we should modify the handler not to do anything unsafe if SIGPROF happens while MPS is processing its SIGSEGV. That's a much more reliable fix, and one that will allow us to keep our profiling code.