From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24640: Crashes in 25.1 Date: Wed, 12 Oct 2016 17:44:55 +0300 Message-ID: <83vawxaaoo.fsf@gnu.org> References: <20161012135020.GA21177@marvin.cs.ucl.ac.uk> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1476283601 10358 195.159.176.226 (12 Oct 2016 14:46:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Oct 2016 14:46:41 +0000 (UTC) Cc: 24640@debbugs.gnu.org, phillip.lord@russet.org.uk, rrt@sc3d.org To: Toby Cubitt Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 12 16:46:37 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 1buKnT-0008GQ-C3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Oct 2016 16:46:19 +0200 Original-Received: from localhost ([::1]:34022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buKnU-00085o-0I for geb-bug-gnu-emacs@m.gmane.org; Wed, 12 Oct 2016 10:46:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buKnH-00083P-45 for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 10:46:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buKnC-0002vQ-3k for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 10:46:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buKnC-0002vM-0Q for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 10:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1buKnB-0007QQ-SR for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2016 10:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Oct 2016 14:46: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.147628352328496 (code B ref 24640); Wed, 12 Oct 2016 14:46:01 +0000 Original-Received: (at 24640) by debbugs.gnu.org; 12 Oct 2016 14:45:23 +0000 Original-Received: from localhost ([127.0.0.1]:53182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buKmV-0007PV-Pm for submit@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buKmU-0007PI-1K for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buKmL-0002lF-0w for 24640@debbugs.gnu.org; Wed, 12 Oct 2016 10:45:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57413) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buKmK-0002k4-Tm; Wed, 12 Oct 2016 10:45:08 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3040 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buKmI-0002lr-VV; Wed, 12 Oct 2016 10:45:07 -0400 In-reply-to: <20161012135020.GA21177@marvin.cs.ucl.ac.uk> (message from Toby Cubitt on Wed, 12 Oct 2016 14:50:20 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:124389 Archived-At: > Date: Wed, 12 Oct 2016 14:50:20 +0100 > Cc: phillip.lord@russet.org.uk, rrt@sc3d.org, 24640@debbugs.gnu.org > From: Toby Cubitt > > On Wed, Oct 12, 2016 at 01:31:05PM +0300, Eli Zaretskii wrote: > > > Date: Tue, 11 Oct 2016 19:33:20 +0300 > > > From: Eli Zaretskii > > > Cc: 24640@debbugs.gnu.org > > > > > > > ​Yes, the crashes appear to stop when I comment out (global-undo-tree-mode) in vars.el. > > You can also disable history loading without disabling > global-undo-tree-mode, by disabling undo-tree-auto-save-history. Might be > worth doing this more fine-grained check to confirm. Thanks for chiming in. > > > Phillip, could you please look into that package and see if you can > > > spot any potential problems with the Emacs 25 undo internals? TIA. > > >From the bug tracker discussion, it sounds like you're close to boiling > this down to some simple steps involving one undo-tree history file that > trigger the crash. They are only simple on Reuben's machine, as they involve a very large setup of his Emacs sessions. We don't have a reproducer for any other machine. 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. > If you can send me the file and a list of steps to reproduce from > emacs -Q, I'd be happy to look into the undo-tree side of things. Thanks. Maybe Reuben will be able to do that. > > 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. > > 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? > 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. > 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. Thanks.