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: Sat, 8 Oct 2016 14:28:48 +0100 Message-ID: References: <83int3idxl.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114013b4d20718053e5a810a X-Trace: blaine.gmane.org 1475933377 1996 195.159.176.226 (8 Oct 2016 13:29:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Oct 2016 13:29:37 +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 Sat Oct 08 15:29:30 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 1bsrgi-0006MY-97 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Oct 2016 15:29:16 +0200 Original-Received: from localhost ([::1]:41141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsrgg-0000BG-M0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Oct 2016 09:29:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsrgY-0000B9-PG for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2016 09:29:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsrgU-0002W0-4w for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2016 09:29:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsrgU-0002Vv-1E for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2016 09:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bsrgT-0000iA-QY for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2016 09:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Oct 2016 13:29: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.14759333382726 (code B ref 24640); Sat, 08 Oct 2016 13:29:01 +0000 Original-Received: (at 24640) by debbugs.gnu.org; 8 Oct 2016 13:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:48371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsrgQ-0000hs-4d for submit@debbugs.gnu.org; Sat, 08 Oct 2016 09:28:58 -0400 Original-Received: from mail-lf0-f50.google.com ([209.85.215.50]:34415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsrgN-0000hd-Hw for 24640@debbugs.gnu.org; Sat, 08 Oct 2016 09:28:56 -0400 Original-Received: by mail-lf0-f50.google.com with SMTP id b81so58991643lfe.1 for <24640@debbugs.gnu.org>; Sat, 08 Oct 2016 06:28:55 -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=jNC0n/P8t/y5YgUjNqv1lGn2cASR5dJyCliIlL36uOI=; b=UKGUoimQL9d35jml7o3ffMlj7gLplPT7Y+kNAxd6BnhF2yc+bklkHWh/6MOckKoaN9 q+7luu77DcGV+DpylWBUF6EPVL3tJYivdOGRiTjTiRGHhZ0F8Z7IM2MSzwfatcX0ZOtJ gtqfi14KFZNgxaDCjSc7lnafT9AJ7YrIX5hEc= 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=jNC0n/P8t/y5YgUjNqv1lGn2cASR5dJyCliIlL36uOI=; b=bNHhopFRG78OYiRbKUEVJKnv7W4diaIZ9ULavT9N2ojHO1mGxsIu4O3yUAKk8KkGiq LdnId0gQiQDI5uKwwK0GwQ07BVW+FWRiqqylXRarahnQ8yLWNOOL24xePtbdcAckf+zt sQ+4eX5wyis0VmQUkcKhjAwSo01MAhfKjL+3In9ycZUXlJuqhd3dEqcMHBMI96EQW+bm GLon1ibOSnxec+8MCUqr/u6HZAkcZIxGxFdunAtWCO5SQUwUHL3eqZDz0eC0ITG6vh2I j5hfYzfw0jQ7OBykvmXLaqoxpe74/IXm+2q+0qmaB/zRDwyljItmpTAqrR2GxiRIR5lA vOxw== X-Gm-Message-State: AA6/9RnayWyg71XXq3HBPMkTeEbZ52i4pqAKewNSPmJzos8PQDv+AUvFc71WzhmnRoHANhlA90YZl7RzXuaQtgh3 X-Received: by 10.46.71.69 with SMTP id u66mr4473346lja.74.1475933329551; Sat, 08 Oct 2016 06:28:49 -0700 (PDT) Original-Received: by 10.25.66.211 with HTTP; Sat, 8 Oct 2016 06:28:48 -0700 (PDT) In-Reply-To: <83int3idxl.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:124202 Archived-At: --001a114013b4d20718053e5a810a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 October 2016 at 06:53, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. > > What does "lazy-loading" mean in this context? > =E2=80=8BWhen desktop(.el) is run at startup, it loads a fixed number of bu= ffers immediately, then lazy-loads the rest. It's during the lazy loading that the crash happens.=E2=80=8B > > I can't tell exactly what it's doing, but it appears to be about the > > same place each time. > > If you run Emacs under GDB, and source the src/.gdbinit file provided > in the source tree, the backtrace command will automatically try to > produce a Lisp-level backtrace as well. That could be helpful. > =E2=80=8BFortunately(!) it is still crashing the same way. Here you go:=E2= =80=8B [New Thread 0x7fffe5960700 (LWP 19613)] [New Thread 0x7fffe4cf1700 (LWP 19614)] [New Thread 0x7fffdfd2d700 (LWP 19615)] Thread 1 "emacs25" received signal SIGSEGV, Segmentation fault. mark_object (arg=3D) at alloc.c:6488 6488 alloc.c: No such file or directory. (gdb) bt 1 #0 0x000000000054aa44 in mark_object (arg=3D) at alloc.c:64= 88 #1 0x000000000054a8fe in mark_object (arg=3D) at alloc.c:64= 52 Lisp Backtrace: "Automatic GC" (0x0) "process-file" (0xffff9ea0) "apply" (0xffff9e98) "vc-git--call" (0xffffa188) "apply" (0xffffa180) "vc-git--out-ok" (0xffffa318) "apply" (0xffffa488) "vc-git--run-command-string" (0xffffa638) "vc-git--symbolic-ref" (0xffffa800) "vc-git-mode-line-string" (0xffffab08) "apply" (0xffffab00) "vc-call-backend" (0xffffad20) "vc-mode-line" (0xffffaf60) "vc-refresh-state" (0xffffb1a8) "auto-revert-handler" (0xffffb388) "auto-revert-buffers" (0xffffb530) "auto-revert-mode" (0xffffb7b0) "desktop-create-buffer" (0xffffb948) "apply" (0xffffbb00) "desktop-lazy-create-buffer" (0xffffbcb0) "desktop-idle-create-buffers" (0xffffbf88) "apply" (0xffffbf80) "timer-event-handler" (0xffffc198)=E2=80=8B > This part of the backtrace, right before the SIGSEGV, makes no sense: > the code at line 2025 of lisp.h does bitwise operations on scalar > values, and y is one such scalar value. Please build without > optimizations, that would make the backtraces more reliable and > detailed. > =E2=80=8BFor now I'll concentrate on the Ubuntu build; I can go back to the self-build later; I've reconfigured the source tree=E2=80=8B with default o= ptions. > Was the Ubuntu package also compiled with Cairo? =E2=80=8BI had a look at the source package, and it doesn't build with --with-cairo, so no. On 8 October 2016 at 06:53, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sat, 8 Oct 2016 00:12:26 +0100 > > > > In both cases, the crash occurs while Emacs is lazy-loading my desktop. > > What does "lazy-loading" mean in this context? > > > I can't tell exactly what it's doing, but it appears to be about the > > same place each time. > > If you run Emacs under GDB, and source the src/.gdbinit file provided > in the source tree, the backtrace command will automatically try to > produce a Lisp-level backtrace as well. That could be helpful. > > This string in the 1st backtrace you show could help figure out what > form was being evaluated: > > #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, > nbytes=3D652, chars=3D0x7fff0376eaa0 > "Unescaped left brace in regex is deprecated, passed through in regex; > marked by <-- HERE in m/\\\\begin{ > <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUnescaped > left brace in regex is depre"..., p=3D0x287) > at process.c:5440 > > The SIGSEGV happens here: > > nextsym: > if (ptr->gcmarkbit) <<<<<<<<<<<<<<<<<< > break; > > So the value of 'ptr' there (frame 20 in the 1st backtrace) is of > interest. > > > =E2=80=8BI tried =E2=80=8Bbuilding the current emacs-25 branch with ./c= onfigure > --with-xwidgets --with-cairo --with-modules, I get > > a different crash: > > [...] > > #6 0x00007f1fd486a3d0 in () at > /lib/x86_64-linux-gnu/libpthread.so.0 > > #7 0x000000000056dd24 in sxhash (y=3D access memory at address 0x0>, > > x=3D0) at lisp.h:2025 > > #8 0x000000000056dd24 in sxhash (len=3D, ptr=3D out>) at fns.c:4246 > > This part of the backtrace, right before the SIGSEGV, makes no sense: > the code at line 2025 of lisp.h does bitwise operations on scalar > values, and y is one such scalar value. Please build without > optimizations, that would make the backtraces more reliable and > detailed. > > Was the Ubuntu package also compiled with Cairo? (I cannot figure out > the build details from the URL you provided, and your report lacks the > details collected by "M-x report-emacs-bug".) If so, please try > building without Cairo, as that option is not yet recommended for > prime time. > > Thanks. > --=20 http://rrt.sc3d.org --001a114013b4d20718053e5a810a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8 October 2016 at 06:53= , Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
>
> In both cases, the crash occurs while Emacs is lazy-loading my desktop= .

What does "lazy-loading" mean in this context?

=E2=80= =8BWhen desktop(.el) is run at startup, it loads a fixed number of buffers=20 immediately, then lazy-loads the rest. It's during the lazy loading tha= t the crash happens.=E2=80=8B
=C2=A0
> I can't tell exactly what it's doing, but it appears to be abo= ut the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.=C2=A0 That could be helpful.

=E2=80=8BFortunately(!) it is still crashing the same way. Here you g= o:=E2=80=8B

[New Thread 0x7fffe5960700 (LWP 19613)]
[New Thread= 0x7fffe4cf1700 (LWP 19614)]
[New Thread 0x7fffdfd2d700 (LWP 19615)]
=
Thread 1 "emacs25" received signal SIGSEGV, Segmentation faul= t.
mark_object (arg=3D<optimised out>) at alloc.c:6488
6488=C2= =A0=C2=A0=C2=A0 alloc.c: No such file or directory.
(gdb) bt 1
#0=C2= =A0 0x000000000054aa44 in mark_object (arg=3D<optimised out>) at allo= c.c:6488
#1=C2=A0 0x000000000054a8fe in mark_object (arg=3D<optimised= out>) at alloc.c:6452

Lisp Backtrace:
"Automatic GC"= ; (0x0)
"process-file" (0xffff9ea0)
"apply" (0xff= ff9e98)
"vc-git--call" (0xffffa188)
"apply" (0xff= ffa180)
"vc-git--out-ok" (0xffffa318)
"apply" (0x= ffffa488)
"vc-git--run-command-string" (0xffffa638)
"v= c-git--symbolic-ref" (0xffffa800)
"vc-git-mode-line-string&quo= t; (0xffffab08)
"apply" (0xffffab00)
"vc-call-backend&= quot; (0xffffad20)
"vc-mode-line" (0xffffaf60)
"vc-ref= resh-state" (0xffffb1a8)
"auto-revert-handler" (0xffffb38= 8)
"auto-revert-buffers" (0xffffb530)
"auto-revert-mod= e" (0xffffb7b0)
"desktop-create-buffer" (0xffffb948)
&= quot;apply" (0xffffbb00)
"desktop-lazy-create-buffer" (0x= ffffbcb0)
"desktop-idle-create-buffers" (0xffffbf88)
"= apply" (0xffffbf80)
"timer-event-handler" (0xffffc198)=E2= =80=8B
=C2=A0
This part of the backtrace, right before the SIGSEGV,= makes no sense:
the code at line 2025 of lisp.h does bitwise operations on scalar
values, and y is one such scalar value.=C2=A0 Please build without
optimizations, that would make the backtraces more reliable and
detailed.

=E2=80=8BFor now I'll concentrate on the Ubuntu build; I can go back to the=20 self-build later; I've reconfigured the source tree=E2=80=8B with defau= lt=20 options.
=C2=A0
Was the Ubuntu package also compiled with Cairo?
=E2=80=8BI had a l= ook at the source package, and it doesn't build with --with-cairo, so n= o.

On 8 October 2016 at 06:53, Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Reuben Thomas = <rrt@sc3d.org>
> Date: Sat, 8 Oct 2016 00:12:26 +0100
>
> In both cases, the crash occurs while Emacs is lazy-loading my desktop= .

What does "lazy-loading" mean in this context?

> I can't tell exactly what it's doing, but it appears to be abo= ut the
> same place each time.

If you run Emacs under GDB, and source the src/.gdbinit file provided
in the source tree, the backtrace command will automatically try to
produce a Lisp-level backtrace as well.=C2=A0 That could be helpful.

This string in the 1st backtrace you show could help figure out what
form was being evaluated:

=C2=A0 #41 0x000000000059af2d in read_process_output (coding=3D0x53b3920, n= bytes=3D652, chars=3D0x7fff0376eaa0
=C2=A0 "Unescaped left brace in regex is deprecated, passed through in= regex; marked by <-- HERE in m/\\\\begin{
=C2=A0 <-- HERE tex}(.*?)\\\\end{tex}/ at /usr/bin/texify line 521.\nUne= scaped left brace in regex is depre"..., p=3D0x287)
=C2=A0 at process.c:5440

The SIGSEGV happens here:

=C2=A0 =C2=A0 =C2=A0 nextsym:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (ptr->gcmarkbit)=C2=A0 <<<<&l= t;<<<<<<<<<<<<<
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;

So the value of 'ptr' there (frame 20 in the 1st backtrace) is of interest.

> =E2=80=8BI tried =E2=80=8Bbuilding the current emacs-25 branch with ./= configure --with-xwidgets --with-cairo --with-modules, I get
> a different crash:
> [...]
> #6 0x00007f1fd486a3d0 in <signal handler called> () at /lib/x86_= 64-linux-gnu/libpthread.so.0
> #7 0x000000000056dd24 in sxhash (y=3D<error reading variable: Canno= t access memory at address 0x0>,
> x=3D0) at lisp.h:2025
> #8 0x000000000056dd24 in sxhash (len=3D<optimised out>, ptr=3D&l= t;optimised out>) at fns.c:4246

This part of the backtrace, right before the SIGSEGV, makes no sense:
the code at line 2025 of lisp.h does bitwise operations on scalar
values, and y is one such scalar value.=C2=A0 Please build without
optimizations, that would make the backtraces more reliable and
detailed.

Was the Ubuntu package also compiled with Cairo?=C2=A0 (I cannot figure out=
the build details from the URL you provided, and your report lacks the
details collected by "M-x report-emacs-bug".)=C2=A0 If so, please= try
building without Cairo, as that option is not yet recommended for
prime time.

Thanks.



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