bug#24640: Crashes in 25.1

[Reuben Thomas <rrt@sc3d.org>]

[-- Attachment #1: Type: text/plain, Size: 5070 bytes --]

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?
>

​When desktop(.el) is run at startup, it loads a fixed number of buffers
immediately, then lazy-loads the rest. It's during the lazy loading that
the crash happens.​


> > 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.
>

​Fortunately(!) it is still crashing the same way. Here you go:​

[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=<optimised out>) at alloc.c:6488
6488    alloc.c: No such file or directory.
(gdb) bt 1
#0  0x000000000054aa44 in mark_object (arg=<optimised out>) at alloc.c:6488
#1  0x000000000054a8fe in mark_object (arg=<optimised out>) at alloc.c:6452

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)​


> 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.
>

​For now I'll concentrate on the Ubuntu build; I can go back to the
self-build later; I've reconfigured the source tree​ with default options.


> Was the Ubuntu package also compiled with Cairo?


​I 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 <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 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=0x53b3920,
> nbytes=652, chars=0x7fff0376eaa0
>   "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=0x287)
>   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.
>
> > ​I tried ​building 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=<error reading variable: Cannot
> access memory at address 0x0>,
> > x=0) at lisp.h:2025
> > #8 0x000000000056dd24 in sxhash (len=<optimised out>, ptr=<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.  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.
>



-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 7386 bytes --]