Emacs segfault

fommil · 2016-10-18 07:10:38

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

It seems like emacs is crashing when loading this s-expression file https://gist.github.com/fommil/d9069188 … 42e1d59b57 which is loaded by https://github.com/ensime/ensime-emacs/ … #L153-L168

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.

Is anybody else seeing this? UPDATE the answer is yes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24358#41

A similar sounding bug report was suggested to me: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24640 But I can reproduce using the emacs-25 branch and also when I reverted back to 24.5... so it's sounding more like the problem is in the system/libc call.

See also the thread on Emacs Help: https://groups.google.com/forum/#!topic … S51V574f2Y

Last edited by fommil (2016-10-18 08:10:52)

FelledTreeNo9 · 2016-10-18 22:19:52

I've been getting segfaults in exactly that same line (regex.c:4464) since upgrading to 25.1. For me it happens during rgrep - which I frequently use to search a particular directory that's full of my personal text files - and it crashes nine times out of ten.

I did a bit of digging with gdb and found very similar things to what they're talking about in that debbugs #24358, particularly that the memory that holds the contents of the buffer (the *grep* output buffer in this case), indicated by current_buffer->text->beg, moves around during an re_search_2() call (rgrep does regexp searches to find the matches in the output to colourize them, I think).

It was all rather time consuming, so I reverted back to 24.5 for the time being. Thanks for finding that debbugs thread, I didn't actually see that one earlier - I'll try and see if I can add anything to it later. In any case, you have my moral support

Last edited by FelledTreeNo9 (2016-10-18 22:20:31)

jethronsun7 · 2016-10-19 01:29:58

Hey there,

I use Emacs as well, have you tried the emacs-git AUR package? It works fine on my Arch

thblt · 2016-10-20 11:11:11

FelledTreeNo9, would you be able to find a reproducible way to trigger a crash (starting with emacs -Q) ? I'm having a very similar bug (in org-mode, random crashes without any identifiable pattern, but backtrace always point somewhere around C regex functions). If you don't have time, and the filenames themselves are not to be treated as confidential, could you provide the output of ls in that directory (and maybe a few examples of regexes you use) so I could try and provide a reproducible recipe to emacs developers? That seems to be missing from bug 24640, where they have to experiment with remote gdb sessions through SSH and similar black magic.

Last edited by thblt (2016-10-20 11:41:17)

FelledTreeNo9 · 2016-10-21 01:38:24

Hi thblt,

My crash seems to be described perfectly by bug 24358, right down to the function and line where the segfault happens, and various other technical details which are mentioned in that thread. I've now checked out an Emacs from the Git tag "emacs-25.1", applied the "v2-0001-Fix-handling-of-allocation-in-regex-matching.patch" from the bug 24358 thread, compiled and run that, and my problem seems to have gone (even running without -Q. When I said it "crashes nine times out of ten", that was without -Q. Whereas with -Q, it still crashed but more rarely - maybe one time in four, making it harder to find a good shareable test case - I did try a bit more to do that earlier today, but didn't have much success). I haven't tested it very much yet (need to replace my system-installed Emacs with this new compile) but it seems positive, at least for me.

Reading the bug 24640 thread, it sounds like they've come to a fix for that one too, in the last post. I reckon you should check out the current "emacs-25" branch (specifically, make sure it includes the commit 10835b1, whose log message references that bug), perhaps also apply the "v2-0001-Fix-handling-of-allocation-in-regex-matching.patch" from the other thread in case you're getting hit by that instead/also, and continue from there.

(By the way while applying the v2-...patch to either "emacs-25.1" or "emacs-25" I do get this:
patching file src/regex.h
Hunk #1 FAILED at 169.
but it just seems to be a comment that failed to change - I ignored it rather than fixed it.)

Arch Linux

#1 2016-10-18 07:10:38

Emacs segfault

#2 2016-10-18 22:19:52

Re: Emacs segfault

#3 2016-10-19 01:29:58

Re: Emacs segfault

#4 2016-10-20 11:11:11

Re: Emacs segfault

#5 2016-10-21 01:38:24

Re: Emacs segfault

Board footer