From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.bugs Subject: bug#24640: Crashes in 25.1 Date: Wed, 12 Oct 2016 17:56:56 +0100 Message-ID: <20161012165656.GA19297@marvin.cs.ucl.ac.uk> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1476291518 20098 195.159.176.226 (12 Oct 2016 16:58:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 16:58:38 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: 24640@debbugs.gnu.org, phillip.lord@russet.org.uk, rrt@sc3d.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 12 18:58:33 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buMrC-0002iv-Th for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Oct 2016 18:58:19 +0200 Original-Received: from localhost ([::1]:34788 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buMrB-0007Bm-L9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Oct 2016 12:58:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buMqz-00078f-Rf for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 12:58:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buMqv-0002u4-Sn for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 12:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buMqv-0002u0-P1 for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 12:58:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1buMqv-0003q8-KM for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 12:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Toby Cubitt Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Oct 2016 16:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24640 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24640-submit@debbugs.gnu.org id=B24640.147629142814694 (code B ref 24640); Wed, 12 Oct 2016 16:58:01 +0000 Original-Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 16:57:08 +0000 Original-Received: from localhost ([127.0.0.1]:53269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buMq4-0003ow-7s for submit@debbugs.gnu.org; Wed, 12 Oct 2016 12:57:08 -0400 Original-Received: from sanddollar.geekisp.com ([216.168.135.167]:1649) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1buMq3-0003oL-DC for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 12:57:07 -0400 Original-Received: (qmail 15431 invoked by uid 1003); 12 Oct 2016 16:51:35 -0000 Original-Received: from marvin.localdomain (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Wed, 12 Oct 2016 12:51:31 -0400 Original-Received: by marvin.localdomain (Postfix, from userid 1000) id 7F7A812150E7; Wed, 12 Oct 2016 17:56:56 +0100 (BST) Content-Disposition: inline In-Reply-To: <83vawxaaoo.fsf@gnu.org> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124399 Archived-At: On Wed, Oct 12, 2016 at 05:44:55PM +0300, Eli Zaretskii wrote: > What's more, the steps to reproduce may be simple (start Emacs and > wait for it to crash), finding the code that is the culprit for this > is anything but easy. The crash is triggered by GC, and is due to an > invalid object being present in the value of read_objects, which holds > the object read by Emacs with the #n=object form. The problem is that > the faulty object is deep in that list, so catching the code that puts > it there is not easy. I'm still trying to devise a way for that, with > no real success so far. I understand. I can't help at all with the GC bug, unfortunately, as it's well outside my Emacs knowledge. I know what the buffer-undo-tree data structure looks like that gets written and read from file, so if I can help at any point by picking apart or simplifying that lisp structure, let me know. > > > Some functions in undo-tree refer to or manipulate Emacs undo > > > internals: > > > > > > undo-list-pop-changeset > > > undo-list-transfer-to-tree > > > undo-list-rebuild-from-tree > > > undo-tree-pull-undo-in-region-branch > > > undo-tree-pull-redo-in-region-branch > > > undo-tree-adjust-elements-to-elt > > > undo-tree-apply-deltas > > > undo-tree-undo-1 > > > undo-tree-redo-1 > > > > > > Do they perhaps need some adjustments to Emacs 25's undo? > > > > The only Emacs undo internal that undo-tree manipulates is the > > buffer-undo-list variable. The only functions that do so are: > > > > undo-list-pop-changeset > > undo-list-transfer-to-tree > > undo-list-rebuild-from-tree > > > > All the others either call one of these, or only touch buffer-undo-tree > > which is a variable defined in the undo-tree package and which the Emacs > > undo internals know nothing about. > > > > Has the format of buffer-undo-list has changed at all? If so, then the > > three above might need adjustment. If not, they should work as before. > > > > The only other Emacs undo internals used by undo-tree are to call > > primitive-undo and undo-boundary when undo/redoing. > > I counted this last class among those listed above. Indeed. I was attempting to explain which ones manipulate buffer-undo-list "behind Emacs' back", and which ones just call out to undo functions. In case it helps, note that none of the above functions get called when reloading history from file. > > > Another potential issue is the new undo timer we have in Emacs 25 (see > > > undo-auto--boundary-ensure-timer in simple.el). One way of checking > > > whether this is related to the crashes is to modify that function to > > > use a much larger value for the 1st argument of run-at-time, say > > > 10000, so that the undo timer never fires during the startup. Reuben, > > > could you try that? > > > > As far as I understand, the timer just adds undo boundaries to > > buffer-undo-list in some of the open buffers. Undo-tree doesn't touch > > buffer-undo-list (or do anything at all, in fact) until you call one of > > its interactive commands. > > Does restoring undo-tree history manipulates buffer-undo-list of any > buffers in any way? No. It just reads a lisp structure from file into the buffer-undo-tree variable. > > Since the timer can't run whilst undo-tree lisp code is running > > It can run if during restoring the history, undo-tree calls sit-for, or > asks a question, or calls some other API that enters redisplay and/or > involves user input. During history loading it doesn't access buffer-undo-list at all, so it shouldn't matter if the timer runs. When undoing, everything that accesses or touches buffer-undo-list is encapsulated in the three functions I listed. None of these call sit-for, prompt for input, or display anything. As far as I understand it, they shouldn't be able to trigger redisplay at all (caveat I'm no redisplay expert - that's you!) I don't think the undo timer can trigger elsewhere during undo-tree undo. Even if it does somehow trigger outside those three functions, this shouldn't break anything. Depending on when it triggers, undo-tree will either pick up the extra undo boundary added to buffer-undo-list this time around, or next time you undo. > > I'd be surprised if the new undo timer is the culprit. > > It could be a culprit, but evidently isn't, as Reuben already tried to > disable it. Indeed. But even if it's not to blame here, I still ought double-check the above carefully to make sure the new undo timer doesn't interact with undo-tree in some subtle way I've overlooked. Cheers, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Quantum Information Theory Department of Computer Science University College London email: tsc25@cantab.net web: www.dr-qubit.org