GNU bug report logs - #27585
segfault when evaluating a file containing only backticks

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#27585: closed (segfault when evaluating a file containing
 only backticks)
Date: Fri, 14 Jul 2017 12:10:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 14 Jul 2017 05:09:34 -0700
with message-id <070206be-9f8b-a324-0650-fd21b37a4132 <at> cs.ucla.edu>
and subject line Re: bug#27585: segfault when evaluating a file containing only backticks
has caused the debbugs.gnu.org bug report #27585,
regarding segfault when evaluating a file containing only backticks
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
27585: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27585
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Steve Kemp <steve <at> steve.org.uk>
To: bug-gnu-emacs <at> gnu.org
Subject: segfault when evaluating a file containing only backticks
Date: Wed, 05 Jul 2017 06:21:10 +0000

  I've recently started fuzzing GNU Emacs, using the current git sources.
 During the course of that work I stumbled upon this easily reproduced bug:

   deagol ~ $ perl -e 'print "`" x ( 1024 * 1024  * 12);' > t.el
   deagol ~ $ /usr/bin/emacs --batch --script ./t.el
   ..
   Segmentation fault (core dumped)

  (So I'm trying to call "emacs --batch --script $file" where the file
 contains thousands of repeated backtick-characters.)

  Because I've built from source I can see this backtrace:

#5  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>)
    at sysdep.c:1811
#6  <signal handler called>
#7  read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc661e010, first_in_list=first_in_list <at> entry=false)
    at lread.c:2923
#8  0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#9  read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc66220c0, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#10 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#11 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc6626170, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#12 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#13 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc662a220, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#14 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#15 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc662e2d0, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#16 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#17 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc6632380, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#18 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#19 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc6636430, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
#20 0x0000000000ad8cda in read0 (readcharfun=35581829) at lread.c:2220
#21 read1 (readcharfun=readcharfun <at> entry=35581829, 
    pch=pch <at> entry=0x7ffcc663a4e0, first_in_list=first_in_list <at> entry=false)
    at lread.c:3149
....


  I've replicated this upon the package of GNU Emacs as available to
 the old-stable/jessie release of Debian GNU/Linux, which identifies
 itself as:


In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
 of 2016-03-19 on trouble, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8.8 (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'
 

  My current-git build reports as:

In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu)
 of 2017-07-05 built on kernel.default.skx.uk0.bigv.io
Repository revision: 5d62247323f53f3ae9c7d9f51e951635887b2fb6
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --prefix=/tmp/emacs/ --without-makeinfo --with-gnutls=no'

Configured features:
SOUND NOTIFY ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF8
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

  "Obviously" this same bug can be reproduced inside emacs:

    1.  Open Emacs.
    2.  Create a new buffer.
    3.  Fill the buffer with `
    4.  Ctrl-x h
    5.  M-x eval-region



Steve
-- 
https://www.steve.org.uk/

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Steve Kemp <steve <at> steve.org.uk>
Cc: 27585-done <at> debbugs.gnu.org
Subject: Re: bug#27585: segfault when evaluating a file containing only
 backticks
Date: Fri, 14 Jul 2017 05:09:34 -0700

[Message part 4 (text/plain, inline)]

Thanks for reporting the bug. I reproduced the problem on Fedora 26 x86-64, 
fixed it in master by applying the attached patch, and am boldly marking the bug 
as fixed.

As Eli and Daniel mentioned, this area of Emacs cannot be 100% reliable and to 
some extent is indeed a "ticking time bomb". That being said, the problem in 
this particular case was that Emacs had a bad heuristic for guessing whether a 
segmentation violation address was due to stack overflow on GNU/Linux. This bad 
heuristic has been in place for years without anybody reporting it. It's good 
that we fixed this bug (though I hope "normal" users never notice the bug fix :-).

[0001-Improve-stack-overflow-heuristic-on-GNU-Linux.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.