From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] Date: Sat, 2 Jul 2022 20:27:32 +0000 Message-ID: References: <83sfnsadow.fsf@gnu.org> <83o7yg9f0w.fsf@gnu.org> <83r1396lvr.fsf@gnu.org> <83edz87ivz.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7762"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 02 22:28:49 2022 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 1o7jjV-0001tK-5W for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 22:28:49 +0200 Original-Received: from localhost ([::1]:56090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7jjT-0002yS-Tw for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 16:28:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44040) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7jiL-0002Ah-RE for emacs-devel@gnu.org; Sat, 02 Jul 2022 16:27:37 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:53922 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1o7jiJ-0006ba-MD for emacs-devel@gnu.org; Sat, 02 Jul 2022 16:27:37 -0400 Original-Received: (qmail 14722 invoked by uid 3782); 2 Jul 2022 20:27:33 -0000 Original-Received: from acm.muc.de (p4fe15928.dip0.t-ipconnect.de [79.225.89.40]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Jul 2022 22:27:32 +0200 Original-Received: (qmail 29003 invoked by uid 1000); 2 Jul 2022 20:27:32 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.devel:291801 Archived-At: Hello, Stefan. On Thu, Jun 30, 2022 at 16:34:23 -0400, Stefan Monnier wrote: > >> That's where we currently log all the errors during redisplay, since > >> Emacs 21.1. So why this one is different? > > It's not a single line, or a small number of lines. It could potentially > > be a stack overflow error, generating a large backtrace, which might have > > more lines than message-log-max. > How 'bout stashing the backtrace data in a var (without turning it into > text yet; that ..... Does "that" mean the stashing or the turning into text? > .... should always be quick, safe, and painless) and then adding a > button in the *Messages* (or *Warnings*) next to the error itself such > that pressing the buttong shows you the actual backtrace? I'm not sure the stashing of the backtrace data is a good idea. It's likely to be BIG (see above), and it's fragile - the only place to record it is in signal_or_quit, before it gets discarded by a call to unwind_to_catch. The need to know its precise format is obviated by the C function mapbacktrace, so we might as well just dump out the backtrace as text in *Backtrace* at the first opportunity. There's nothing time critical about the said dumping. > We could even try and get fancy: instead of only stashing the > `backtrace-frames`, we could also stash a copy of the specpdl so we > could bring up a *Backtrace* buffer which isn't quite "live" but can > still be used to some extent to see the values of local vars (and > `current-buffer`) in the different activation frames. I think that's very ambitious. Surely the time for that is when the basic backtrace functionality is working, and the need for something more sopisticated is perceived. > BTW, in order to debug fontification errors, we also have > `jit-locak-debug-mode` which postpones the jit/font-lock execution from > within redisplay to "just a bit later" such that it can use the > debugger. IIRC it still has some rough edges in some cases, but in > theory it should be possible to make this work such that you can (for > example) Edebug `font-lock.el` itself. It does work, though, doesn't it? > Stefan -- Alan Mackenzie (Nuremberg, Germany).