From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#24640: Crashes in 25.1 Date: Tue, 11 Oct 2016 15:08:45 +0100 Message-ID: References: <83int3idxl.fsf@gnu.org> <83mviehq0p.fsf@gnu.org> <83eg3qhn29.fsf@gnu.org> <83vax2f1e5.fsf@gnu.org> <83r37pg7zl.fsf@gnu.org> <83y41wenld.fsf@gnu.org> <834m4kduzl.fsf@gnu.org> <831szodsus.fsf@gnu.org> <83zimccbzr.fsf@gnu.org> <83lgxvcd10.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11401a2c32934a053e976ae1 X-Trace: blaine.gmane.org 1476195192 22687 195.159.176.226 (11 Oct 2016 14:13:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Oct 2016 14:13:12 +0000 (UTC) Cc: 24640@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 11 16:13:04 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 1btxnf-0004U5-VW for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Oct 2016 16:13:00 +0200 Original-Received: from localhost ([::1]:56043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btxne-0005BL-JX for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Oct 2016 10:12:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46972) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btxju-0002F7-O9 for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2016 10:09:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btxjq-0000Y6-Kc for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2016 10:09:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btxjq-0000Xz-Hb for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2016 10:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1btxjq-0002qs-51 for bug-gnu-emacs@gnu.org; Tue, 11 Oct 2016 10:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Oct 2016 14:09:02 +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.147619494010954 (code B ref 24640); Tue, 11 Oct 2016 14:09:02 +0000 Original-Received: (at 24640) by debbugs.gnu.org; 11 Oct 2016 14:09:00 +0000 Original-Received: from localhost ([127.0.0.1]:52264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btxjm-0002qY-Fi for submit@debbugs.gnu.org; Tue, 11 Oct 2016 10:09:00 -0400 Original-Received: from mail-lf0-f53.google.com ([209.85.215.53]:34153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btxjg-0002qF-7G for 24640@debbugs.gnu.org; Tue, 11 Oct 2016 10:08:56 -0400 Original-Received: by mail-lf0-f53.google.com with SMTP id b81so42572800lfe.1 for <24640@debbugs.gnu.org>; Tue, 11 Oct 2016 07:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lm6YSj/eRbRc2VOWFP8ecctp3J+lCoOSrGANKTv4Rr0=; b=hhhSMzlIOLkNUZuIhVpky1hoUjvv1Y0ItdpV7CmHnqZfRKOGPg/mZgxZdlUUZ1mcBc 1sNqzCRm+bTAmEaMrHwBbw0Es5rnLp8ymatdV7yRS5tyVKGMcReI4meFrlYQI0W+XVqH K4iCWa/OGSPx3PF/aQKZdnvT8c7KKCOLWeYrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lm6YSj/eRbRc2VOWFP8ecctp3J+lCoOSrGANKTv4Rr0=; b=XmnpLAHdpgrP7R3fIfGSnR9a0UWjbIPrUOqGPHlfjdEClvPNo/0HwFb7KeCk+O/FOb d4vwTg1KjKx+4GqbTMMD1fxUqwtqAYKerzjQm6VN5nLP3Ck29yB5Bdh5bTr4UEuvvRe6 WlsZZxQd1clY71vda8GmgjtbPXThhZBiGTB48H5awSlvN2jUpLXI7eBIuwFj7Ngs4pgr fpEOnSpzVT+tWloa72knkZ7SbBCW+bRyRdE/q3SBNJo/1jDiR0KjBvvE/OhiX6ueiGVZ 0so8Qn61Cvmng21zi8w5wAzr/nlneRN5H2Cj/QxPTLkb9qom9RT2hX5w/d1kXgPs1nak h9ZA== X-Gm-Message-State: AA6/9RlOBGRhGoY/jpyyYlmYw2wNJnDikahPMwdri+JWZy1uYWsykrikcpLfW8dv+coO4MioP6njxNBYYMpX+JTG X-Received: by 10.25.154.132 with SMTP id c126mr3092029lfe.58.1476194926232; Tue, 11 Oct 2016 07:08:46 -0700 (PDT) Original-Received: by 10.25.66.211 with HTTP; Tue, 11 Oct 2016 07:08:45 -0700 (PDT) In-Reply-To: <83lgxvcd10.fsf@gnu.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:124333 Archived-At: --001a11401a2c32934a053e976ae1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 October 2016 at 12:59, Eli Zaretskii wrote: > Thanks, I've done some initial debugging. The crash seems to be > related to the variable read_objects, defined and used by lread.c. It > is an alist of objects read with the #n=3Dobject form. One of its > members is a corrupted Lisp object, which causes the GC crash when > this object is examined. > =E2=80=8BGood stuff! > read_objects is a global variable, so it could be that some code > invoked in the middle of reading one #n=3Dobject form clobbers it by > reading another. However, I don't immediately see such forms in the > few of your many init files I looked in. =E2=80=8B Indeed, I'm not aware of having used such a form myself, nor can I find one by grepping. > Do you have any idea where > =E2=80=8B =E2=80=8B > this could come from? =E2=80=8BNo, sorry.=E2=80=8B > One place they are abundant is in *.elc files, > so maybe some recursive load together with the timer-based lazy > desktop operation does that? I don't really have a working hypothesis > for now. > Could it be loading the undo-tree undo history? The crash always seems to happen when loading mit.tex. It tries to load the undo-tree history, fails (because the file has been changed since the history was last saved), then crashes. The undo-tree history is full of #n=3Dobject forms. I can let you have the undo-tree history file if that might help you identify the corrupted data. > I'm not an expert on X tricks -- is there any way you can trick Emacs > to start a GUI session when I invoke it via SSH? Some trick with the > value of DISPLAY in the environment, perhaps? I don't need to see > what Emacs displays, just run it live under GDB. The problem that > causes the crash happens before the code I see in the backtrace -- > that code just triggers GC. So it would be beneficial to run Emacs > under GDB and try to see, for example, what code changes read_objects > and how (assuming it is not changed to a non-nil value too many > times). Can this be arranged? > =E2=80=8BIf you use "ssh -X", you can get an X connection and Emacs will st= art a GUI session. That's the simplest thing I can think of; not really a trick at all.=E2=80=8B --=20 http://rrt.sc3d.org --001a11401a2c32934a053e976ae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 11 October 2016 at 12:59, Eli Zaretskii <eliz@gnu.org> wrote:
=
Thanks, I've done some initial debugging.=C2=A0 The cra= sh seems to be
related to the variable read_objects, defined and used by lread.c.=C2=A0 It=
is an alist of objects read with the #n=3Dobject form.=C2=A0 One of its
members is a corrupted Lisp object, which causes the GC crash when
this object is examined.

=E2=80=8BGood stuff!
=C2=A0
read_objects is a global vari= able, so it could be that some code
invoked in the middle of reading one #n=3Dobject form clobbers it by
reading another.=C2=A0 However, I don't immediately see such forms in t= he
few of your many init files I looked in.
=E2=80=8B
Indeed, I'm not aware of having used s= uch a form myself, nor can I find one by grepping.
=C2=A0
=C2=A0 Do you have any idea where
=E2=80=8B = =E2=80=8B
this could come from?

=E2=80=8BNo, sorry.=E2=80= =8B
=C2=A0
=C2=A0 One p= lace they are abundant is in *.elc files,
so maybe some recursive load together with the timer-based lazy
desktop operation does that?=C2=A0 I don't really have a working hypoth= esis
for now.

Could it be loading the undo-tree undo history? Th= e crash always seems to happen when loading mit.tex. It tries to load the u= ndo-tree history, fails (because the file has been changed since the histor= y was last saved), then crashes. The undo-tree history is full of #n=3Dobje= ct forms.

<= /div>
I can let you h= ave the undo-tree history file if that might help you identify the corrupte= d data.
=C2=A0
I'm = not an expert on X tricks -- is there any way you can trick Emacs
to start a GUI session when I invoke it via SSH?=C2=A0 Some trick with the<= br> value of DISPLAY in the environment, perhaps?=C2=A0 I don't need to see=
what Emacs displays, just run it live under GDB.=C2=A0 The problem that
causes the crash happens before the code I see in the backtrace --
that code just triggers GC.=C2=A0 So it would be beneficial to run Emacs under GDB and try to see, for example, what code changes read_objects
and how (assuming it is not changed to a non-nil value too many
times).=C2=A0 Can this be arranged?

=E2=80=8BIf you use &qu= ot;ssh -X", you can get an X connection and Emacs will start a GUI ses= sion. That's the simplest thing I can think of; not really a trick at a= ll.=E2=80=8B

--
http://rrt.sc3d.org
--001a11401a2c32934a053e976ae1--