help debugging a segfault

help debugging a segfault

[Sam Halliday]

Hi all,

Despite being very stable since I installed it when released, Emacs 25.1 has started to segfault on me this week in a hard-to-reproduce manner.

I use ArchLinux and I recompiled with debugging symbols to obtain a detailed core dump / crash log.

But this is all I got when running with gdb until it crashed:

=============================
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
re_search_2 (bufp=bufp@entry=0xc2d460 <searchbufs+2912>, str1=str1@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size1=size1@entry=0, 
    str2=str2@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size2=65565, startpos=646, startpos@entry=623, range=509, 
    regs=0xc2c8d0 <search_regs>, stop=1155) at regex.c:4464
4464		      int len = BYTES_BY_CHAR_HEAD (*p);
=============================


When this happens I have just typed `M-x ensime` and it seems like emacs is crashing when loading the .ensime file, which is an s-expression file that is loaded as data in https://github.com/ensime/ensime-emacs/blob/master/ensime-config.el#L153-L168 (actually if anybody knows of a more efficient way to load the file, I'd be keen to update our code, I'm a maintainer).

The exact file that it is apparently performing the re_search within is https://gist.github.com/fommil/d906918819cd2632e9864842e1d59b57


Could anybody please shed some light on what could be going wrong? I also have a core dump file but I have no idea what to do with it, I've never used gdb in anger.


Almost certainly an ArchLinux system update occurred somewhere around the time that this happened. Emacs is the only app that suffers and I get exactly the same behaviour on my laptop, so I'm ruling out a memory defect.

This is almost certainly a problem with my OS... is anybody else seeing this?

I may crosspost on ArchLinux and reference back here.

Best regards,
Sam

Re: help debugging a segfault

[Sam Halliday]

On Monday, 17 October 2016 21:16:35 UTC+1, Sam Halliday  wrote:
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> re_search_2 (bufp=bufp@entry=0xc2d460 <searchbufs+2912>, str1=str1@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size1=size1@entry=0, 
>     str2=str2@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size2=65565, startpos=646, startpos@entry=623, range=509, 
>     regs=0xc2c8d0 <search_regs>, stop=1155) at regex.c:4464
> 4464		      int len = BYTES_BY_CHAR_HEAD (*p);
... 
> Could anybody please shed some light on what could be going wrong? I also have a core dump file but I have no idea what to do with it, I've never used gdb in anger.

Typing "bt" when loading the coredump gives

(gdb) bt
#0  0x00007fe8cbfabf5f in ?? ()
#1  0x00000000005da106 in mapcar1 (leni=11, vals=<optimized out>, fn=40, seq=498) at fns.c:2494
#2  0xffffffffffffffff in ?? ()
#3  0xffffffffffffffff in ?? ()
#4  0xffffffffffffffff in ?? ()
#5  0xffffffffffffffff in ?? ()
#6  0xffffffffffffffff in ?? ()
#7  0xffffffffffffffff in ?? ()
#8  0xffffffffffffffff in ?? ()
#9  0x000000000000000b in ?? ()
#10 0x00000000004ee994 in Finternal_merge_in_global_face (face=2, frame=12113136) at xfaces.c:3669
#11 0x0000000000000000 in ?? ()

Re: help debugging a segfault

[Eli Zaretskii]

> Date: Mon, 17 Oct 2016 13:28:01 -0700 (PDT)
> From: Sam Halliday <sam.halliday@gmail.com>
> 
> Typing "bt" when loading the coredump gives
> 
> (gdb) bt
> #0  0x00007fe8cbfabf5f in ?? ()
> #1  0x00000000005da106 in mapcar1 (leni=11, vals=<optimized out>, fn=40, seq=498) at fns.c:2494
> #2  0xffffffffffffffff in ?? ()
> #3  0xffffffffffffffff in ?? ()
> #4  0xffffffffffffffff in ?? ()
> #5  0xffffffffffffffff in ?? ()
> #6  0xffffffffffffffff in ?? ()
> #7  0xffffffffffffffff in ?? ()
> #8  0xffffffffffffffff in ?? ()
> #9  0x000000000000000b in ?? ()
> #10 0x00000000004ee994 in Finternal_merge_in_global_face (face=2, frame=12113136) at xfaces.c:3669
> #11 0x0000000000000000 in ?? ()

This is an optimized build, which is very hard to debug.  I suggest to
reconfigure with "-O0 -gdwarf-4- g3" in CFLAGS, as proposed in
etc/DEBUG.

And please post the details to bug 24358 instead of here.

Thanks.

Re: help debugging a segfault

[Sam Halliday]

On Monday, 17 October 2016 21:28:18 UTC+1, Sam Halliday  wrote:
> On Monday, 17 October 2016 21:16:35 UTC+1, Sam Halliday  wrote:
> > Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> > re_search_2 (bufp=bufp@entry=0xc2d460 <searchbufs+2912>, str1=str1@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size1=size1@entry=0, 
> >     str2=str2@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size2=65565, startpos=646, startpos@entry=623, range=509, 
> >     regs=0xc2c8d0 <search_regs>, stop=1155) at regex.c:4464
> > 4464		      int len = BYTES_BY_CHAR_HEAD (*p);
> ... 
> > Could anybody please shed some light on what could be going wrong? I also have a core dump file but I have no idea what to do with it, I've never used gdb in anger.
> 
> Typing "bt" when loading the coredump gives
> 
> (gdb) bt
> #0  0x00007fe8cbfabf5f in ?? ()
> #1  0x00000000005da106 in mapcar1 (leni=11, vals=<optimized out>, fn=40, seq=498) at fns.c:2494
> #2  0xffffffffffffffff in ?? ()
> #3  0xffffffffffffffff in ?? ()
> #4  0xffffffffffffffff in ?? ()
> #5  0xffffffffffffffff in ?? ()
> #6  0xffffffffffffffff in ?? ()
> #7  0xffffffffffffffff in ?? ()
> #8  0xffffffffffffffff in ?? ()
> #9  0x000000000000000b in ?? ()
> #10 0x00000000004ee994 in Finternal_merge_in_global_face (face=2, frame=12113136) at xfaces.c:3669
> #11 0x0000000000000000 in ?? ()

It was suggested to me that this could be http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24640 but I was able to reproduce with the emacs-25 git branch :-(

Re: help debugging a segfault

[Eli Zaretskii]

> Date: Tue, 18 Oct 2016 00:35:35 -0700 (PDT)
> From: Sam Halliday <sam.halliday@gmail.com>
> 
> It was suggested to me that this could be http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24640 but I was able to reproduce with the emacs-25 git branch :-(

That bug doesn't look similar to this one at at all.  But bug#24358
does.

Re: help debugging a segfault

[Óscar Fuentes]

Sam Halliday <sam.halliday@gmail.com> writes:

[snip]

> When this happens I have just typed `M-x ensime` and it seems like
> emacs is crashing when loading the .ensime file, which is an
> s-expression file that is loaded as data in
> https://github.com/ensime/ensime-emacs/blob/master/ensime-config.el#L153-L168
> (actually if anybody knows of a more efficient way to load the file,
> I'd be keen to update our code, I'm a maintainer).
>
> The exact file that it is apparently performing the re_search within
> is https://gist.github.com/fommil/d906918819cd2632e9864842e1d59b57
>
>
> Could anybody please shed some light on what could be going wrong? I
> also have a core dump file but I have no idea what to do with it, I've
> never used gdb in anger.

[snip]

Hmmm... On Emacs bug#24640 it was mentioned that loading an
s-expression-based data file (generated by undo-tree) was suspected to
cause a crash. I don't know if, at the end, that was related to the bug
or just speculation. It was marked as fixed on the emacs-25 branch.
Maybe you could try it?

The bug report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24640

Re: help debugging a segfault

[Eli Zaretskii]

> Date: Mon, 17 Oct 2016 13:16:33 -0700 (PDT)
> From: Sam Halliday <sam.halliday@gmail.com>
> 
> Despite being very stable since I installed it when released, Emacs 25.1 has started to segfault on me this week in a hard-to-reproduce manner.
> 
> I use ArchLinux and I recompiled with debugging symbols to obtain a detailed core dump / crash log.
> 
> But this is all I got when running with gdb until it crashed:
> 
> =============================
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> re_search_2 (bufp=bufp@entry=0xc2d460 <searchbufs+2912>, str1=str1@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size1=size1@entry=0, 
>     str2=str2@entry=0x597b790 <error: Cannot access memory at address 0x597b790>, size2=65565, startpos=646, startpos@entry=623, range=509, 
>     regs=0xc2c8d0 <search_regs>, stop=1155) at regex.c:4464
> 4464		      int len = BYTES_BY_CHAR_HEAD (*p);
> =============================

Sounds like another case of bug#24358, see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#41

and the following discussion.  Your OS is also the same as reported
there, which increases the probability of this being the same issue.

If you ever succeed in getting meaningful data about the crash, or
some way of reproducing it, please post to 24358@debbugs.gnu.org.