From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Fontification error backtrace [Was: Why is it so difficult to get a Lisp backtrace?] Date: Sat, 02 Jul 2022 17:12:50 -0400 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 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12356"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 02 23:13:45 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 1o7kQy-0002z2-CM for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 23:13:44 +0200 Original-Received: from localhost ([::1]:37140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7kQw-0005BB-Vp for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 17:13:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50410) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7kQI-0004Vd-Pi for emacs-devel@gnu.org; Sat, 02 Jul 2022 17:13:02 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11837) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7kQG-0002oR-0p; Sat, 02 Jul 2022 17:13:01 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2D478440C59; Sat, 2 Jul 2022 17:12:58 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6FB93440F6B; Sat, 2 Jul 2022 17:12:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1656796372; bh=BAhDETY9rzdKTMhI6KMT+vAFtgtkWM5GK1RQUSBjlys=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=PpFRCPyMRQpQvcLBxR4PLUiv31Cbnx2I5s3zXU5H3MzUiEep/M4CgGhnFpekrSeNL WSveBkhUmqEiyCGDtL52DuOyszpJdbM+GvaFAUcIfESBhcYKCvEpYLastOea9jSiSq r295QtHcF1CQmSHv5odNbVkCfna3Is1hplwbv1ZEUHcpT9dDtoc9qZHHo+XjsLvT6k 94rIzPOlJ1yT9HaKHRAC4doVkyqGH7OInWdPrnrhQUtynGVP2kcBo6ojeo7vkRlJ17 KroRhYmEHV1uOkMDKGpsqTzDF3+SoBprYGJ0n/lUrSnbzyZODcOEeOOGZqiF3U8w+v rXz2KiswdC5bQ== Original-Received: from alfajor (unknown [45.72.196.165]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20E04120478; Sat, 2 Jul 2022 17:12:52 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sat, 2 Jul 2022 20:27:32 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:291803 Archived-At: Alan Mackenzie [2022-07-02 20:27:32] wrote: > 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? It meant "stashing". >> .... 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 I don't see the "above" that explains why you think it's going to be BIG. Neither do I understand why you think it would be 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. As I mentioned in another message, I think it would make sense to "always" stash backtraces when we get an unhandled error, and then to offer a way to investigate these "post mortem". Think of it as Emacs's equivalent of Unix's core dumps. >> 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. I don't think it's should be terribly hard. We already support multiple specpdl and switching between them for the purpose of threads, so most of the delicate part of the code is already written. >> 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? Yes. Stefan