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? > ​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=) at alloc.c:6488 6488 alloc.c: No such file or directory. (gdb) bt 1 #0 0x000000000054aa44 in mark_object (arg=) at alloc.c:6488 #1 0x000000000054a8fe in mark_object (arg=) 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 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=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 () at > /lib/x86_64-linux-gnu/libpthread.so.0 > > #7 0x000000000056dd24 in sxhash (y= access memory at address 0x0>, > > x=0) at lisp.h:2025 > > #8 0x000000000056dd24 in sxhash (len=, ptr= 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