unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dan Faudemer <dan.faudemer@gmail.com>
Cc: 17288-done@debbugs.gnu.org
Subject: bug#17288: SegFault with emacs in CPP header file (long constructor)
Date: Fri, 18 Apr 2014 11:41:58 +0300	[thread overview]
Message-ID: <83sipbghbd.fsf@gnu.org> (raw)
In-Reply-To: <CAB2rMboZbTUeT6pEwOz-V0WzD=FuvQyUTOuRC8CuD29Oqcjsyg@mail.gmail.com>

> Date: Thu, 17 Apr 2014 14:04:44 +0200
> From: Dan Faudemer <dan.faudemer@gmail.com>
> 
> I have some issue with emacs in a long intialisation constructor, emacs
> exit with a segault.
> 
> My .emacs contains :
> (global-linum-mode 1)
> (set-default 'truncate-lines t)
> 
> And the header file bug.h :
> 
> aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aa
 aaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa"),aaaaaaaaaaa("aaaaaaaaaaa
> aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),
> aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),
> aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),
>                 aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),
> aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),taaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),saaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),gaaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),caaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),laaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),saaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),laaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),_aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),aaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),
> aaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa"),faaaaaaaaaaaaaaaaa("aaaaaaaaaaaaaaaaa")
> 
> To reproduce the segfault you have to put the cursor on the second line
> and press the button to go to the end of the line.

(For me, it happened on line 6, which is second-from-last.)

Thanks, I fixed this for the upcoming Emacs 24.4 release.  If you
build your own Emacs, you can fix your build by applying the one-line
patch at the end of this message.

I'm closing the bug; feel free to reopen if there are any left-overs.

> Fatal error 11: Segmentation fault
> Backtrace:
> /usr/bin/emacs[0x4ef391]
> /usr/bin/emacs[0x4d4dbd]
> /usr/bin/emacs[0x4ef2ee]
> /usr/bin/emacs[0x4ef6a3]
> /lib64/libpthread.so.0[0x2b05af4dbbe0]
> /usr/bin/emacs[0x498926]
> /usr/bin/emacs[0x49c180]
> /usr/bin/emacs[0x43aab9]
> /usr/bin/emacs[0x43abf5]
> /usr/bin/emacs[0x44b2dc]
> /usr/bin/emacs[0x44f0ff]
> /usr/bin/emacs[0x454f8b]
> /usr/bin/emacs[0x457349]
> /usr/bin/emacs[0x545aa3]
> /usr/bin/emacs[0x458675]
> /usr/bin/emacs[0x4e2939]
> /usr/bin/emacs[0x4e4da7]
> /usr/bin/emacs[0x4e6c7b]
> /usr/bin/emacs[0x545bf6]
> /usr/bin/emacs[0x4dd6ea]
> /usr/bin/emacs[0x545cea]
> /usr/bin/emacs[0x4dde40]
> /usr/bin/emacs[0x4ddf8a]
> /usr/bin/emacs[0x4d5ba6]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3affa1d994]
> /usr/bin/emacs[0x413f19]

For the record, here's the backtrace and some relevant variables
printed by GDB:

  Program received signal SIGSEGV, Segmentation fault.
  append_glyph (it=0x7fffffff37b0) at term.c:1491
  1491          glyph->face_id = it->face_id;
  (gdb) p glyph
  $1 = (struct glyph *) 0x0
  (gdb) bt 10
  #0  append_glyph (it=0x7fffffff37b0) at term.c:1491
  #1  0x00000000004a2f53 in produce_glyphs (it=0x7fffffff37b0) at term.c:1627
  #2  0x0000000000449ba8 in produce_special_glyphs (it=0x7fffffff44f0,
      what=<optimized out>) at xdisp.c:24411
  #3  0x0000000000449d02 in insert_left_trunc_glyphs (it=<optimized out>)
      at xdisp.c:18377
  #4  0x0000000000450cef in display_line (it=0x7fffffff6d70) at xdisp.c:19956
  #5  0x00000000004532d8 in try_window (window=<optimized out>, pos=..., flags=1)
      at xdisp.c:16353
  #6  0x0000000000457c12 in redisplay_window (window=12071533,
      just_this_one_p=<optimized out>) at xdisp.c:15879
  #7  0x0000000000459ac9 in redisplay_window_1 (window=140737488304048)
      at xdisp.c:13942
  #8  0x000000000054dd0b in internal_condition_case_1 (bfun=<optimized out>,
      arg=<optimized out>, handlers=<optimized out>, hfun=<optimized out>)
      at eval.c:1327
  #9  0x000000000045ae90 in redisplay_internal () at xdisp.c:13570
  (More stack frames follow...)

  Lisp Backtrace:
  "redisplay_internal (C function)" (0xb63d30)
  (gdb) p i
  $2 = 0
  (gdb) p it->glyph_row->used[it->area]
  $3 = 0
  (gdb) pgrowx it->glyph_row
  (gdb) p it->area
  $4 = LEFT_MARGIN_AREA
  (gdb) p it->glyph_row->glyphs[1]
  $5 = (struct glyph *) 0xadd5a0 <scratch_glyphs>
  (gdb) p it->glyph_row->glyphs[0]
  $6 = (struct glyph *) 0x0

And here's the change that fixes this, which I installed in the
emacs-24 branch:

--- src/xdisp.c	2014-04-17 08:58:59 +0000
+++ src/xdisp.c	2014-04-18 08:35:09 +0000
@@ -18688,6 +18688,7 @@ insert_left_trunc_glyphs (struct it *it)
   truncate_it.current_x = 0;
   truncate_it.face_id = DEFAULT_FACE_ID;
   truncate_it.glyph_row = &scratch_glyph_row;
+  truncate_it.area = TEXT_AREA;
   truncate_it.glyph_row->used[TEXT_AREA] = 0;
   CHARPOS (truncate_it.position) = BYTEPOS (truncate_it.position) = -1;
   truncate_it.object = make_number (0);






      reply	other threads:[~2014-04-18  8:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 12:04 bug#17288: SegFault with emacs in CPP header file (long constructor) Dan Faudemer
2014-04-18  8:41 ` Eli Zaretskii [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83sipbghbd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=17288-done@debbugs.gnu.org \
    --cc=dan.faudemer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).