GNU bug report logs - #9401
24.0.50; Crash during fontification

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9401 in the body.
You can then email your comments to 9401 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Crash during fontification
Date: Mon, 29 Aug 2011 12:10:12 -0400

I can trigger this crash about 50 percent of the time by doing

emacs -q trunk/src/buffer.h
C-s defvar

Emacs then crashes with a segfault.

The problem involves a call to scan_sexps_forward (frame#4) with
from_byte larger than the byte size of the buffer.


In GNU Emacs 24.0.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-08-28 on furball
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  'CC=gcc' 'CFLAGS=-g''



#0  0x00000000004d339e in sub_char_table_ref (table=12557029, c=7077888,
    is_uniprop=0) at chartab.c:214
#1  0x00000000004d3583 in char_table_ref (table=12555781, c=7077888)
    at chartab.c:238
#2  0x00000000004d3603 in char_table_ref (table=13980037, c=7077888)
    at chartab.c:244
#3  0x00000000004d3603 in char_table_ref (table=20726293, c=7077888)
    at chartab.c:244
#4  0x00000000006300a5 in scan_sexps_forward (stateptr=0x7fffffff30b0,
    from=26298, from_byte=48082, end=38471, targetdepth=-10000, stopbefore=0,
    oldstate=12552834, commentstop=0) at syntax.c:3133
#5  0x000000000061e721 in back_comment (from=38165, from_byte=38165, stop=1,
    comnested=0, comstyle=0, charpos_ptr=0x7fffffff3418,
    bytepos_ptr=0x7fffffff3420) at syntax.c:733
#6  0x000000000062c7ec in scan_lists (from=38471, count=-1, depth=0,
    sexpflag=1) at syntax.c:2768
#7  0x000000000062d78c in Fscan_sexps (from=153900, count=-4) at syntax.c:2879
#8  0x00000000005e9321 in Ffuncall (nargs=3, args=0x7fffffff35a0)
    at eval.c:2993
#9  0x000000000063632a in exec_byte_code (bytestr=16912593, vector=16668517,
    maxdepth=12, args_template=12552834, nargs=0, args=0x0) at bytecode.c:785
#10 0x00000000006358e7 in Fbyte_code (bytestr=16912593, vector=16668517,
    maxdepth=12) at bytecode.c:423
#11 0x00000000005e7c59 in eval_sub (form=13302582) at eval.c:2344
#12 0x00000000005e5ce9 in internal_lisp_condition_case (var=12552834,
    bodyform=13302582, handlers=13301958) at eval.c:1445
#13 0x0000000000636ff1 in exec_byte_code (bytestr=14879841, vector=16442533,
    maxdepth=36, args_template=12552834, nargs=0, args=0x0) at bytecode.c:981
#14 0x00000000006358e7 in Fbyte_code (bytestr=14879841, vector=16442533,
    maxdepth=36) at bytecode.c:423
#15 0x00000000005e7c59 in eval_sub (form=13181174) at eval.c:2344
#16 0x00000000005e57f3 in internal_catch (tag=13108082,
    func=0x5e7559 <eval_sub>, arg=13181174) at eval.c:1248
#17 0x0000000000636f81 in exec_byte_code (bytestr=16475201, vector=16727461,
    maxdepth=108, args_template=12552834, nargs=0, args=0x0) at bytecode.c:966
#18 0x00000000005e9d9f in funcall_lambda (fun=16837253, nargs=3,
    arg_vector=0xff3da5) at eval.c:3221
#19 0x00000000005e950c in Ffuncall (nargs=4, args=0x7fffffff4900)
    at eval.c:3039
#20 0x000000000063632a in exec_byte_code (bytestr=20878529, vector=17068181,
    maxdepth=24, args_template=12552834, nargs=0, args=0x0) at bytecode.c:785
#21 0x00000000006358e7 in Fbyte_code (bytestr=20878529, vector=17068181,
    maxdepth=24) at bytecode.c:423
#22 0x00000000005e7c59 in eval_sub (form=14631046) at eval.c:2344
#23 0x00000000005e57f3 in internal_catch (tag=13339906,
    func=0x5e7559 <eval_sub>, arg=14631046) at eval.c:1248
#24 0x0000000000636f81 in exec_byte_code (bytestr=20878657, vector=17068613,
    maxdepth=8, args_template=12552834, nargs=0, args=0x0) at bytecode.c:966
#25 0x00000000005e9d9f in funcall_lambda (fun=17068853, nargs=0,
    arg_vector=0x1047245) at eval.c:3221
....
#55 0x0000000000432aae in safe_call1 (fn=15752850, arg=158376) at xdisp.c:2218
#56 0x00000000004352b0 in handle_fontified_prop (it=0x7fffffff8b50)
    at xdisp.c:3332
#57 0x00000000004344ab in handle_stop (it=0x7fffffff8b50) at xdisp.c:2923
#58 0x000000000043c10e in reseat (it=0x7fffffff8b50, pos=..., force_p=1)
    at xdisp.c:5828
#59 0x0000000000433af8 in init_iterator (it=0x7fffffff8b50, w=0x1296430,
    charpos=39594, bytepos=39594, row=0x0, base_face_id=DEFAULT_FACE_ID)
    at xdisp.c:2633
#60 0x0000000000454c5b in redisplay_window (window=19489845, just_this_one_p=0)
    at xdisp.c:15265
#61 0x000000000044f05a in redisplay_window_0 (window=19489845) at xdisp.c:13320
#62 0x00000000005e5fa3 in internal_condition_case_1 (
    bfun=0x44f01b <redisplay_window_0>, arg=19489845, handlers=12523142,
    hfun=0x44efec <redisplay_window_error>) at eval.c:1529
#63 0x000000000044efcd in redisplay_windows (window=19489845) at xdisp.c:13300
#64 0x000000000044dfa5 in redisplay_internal () at xdisp.c:12877
#65 0x000000000044e7f7 in redisplay_preserve_echo_area (from_where=2)
    at xdisp.c:13128
#66 0x000000000041ffdb in Fredisplay (force=12552834) at dispnew.c:5991
#67 0x00000000005e92fa in Ffuncall (nargs=1, args=0x7fffffffb7b0)
    at eval.c:2990
#68 0x000000000063632a in exec_byte_code (bytestr=9404985, vector=9405021,
    maxdepth=20, args_template=12552834, nargs=0, args=0x0) at bytecode.c:785
#69 0x00000000005e9d9f in funcall_lambda (fun=9404869, nargs=1,
    arg_vector=0x8f825d) at eval.c:3221
...
#93 0x000000000055b370 in Fcommand_execute (cmd=15676706,
    record_flag=12552834, keys=12552834, special=12552834) at keyboard.c:10271
#94 0x00000000005497a8 in command_loop_1 () at keyboard.c:1572
#95 0x00000000005e5e3c in internal_condition_case (
    bfun=0x548f00 <command_loop_1>, handlers=12604850,
    hfun=0x5487db <cmd_error>) at eval.c:1491
#96 0x0000000000548bf7 in command_loop_2 (ignore=12552834) at keyboard.c:1156
#97 0x00000000005e57f3 in internal_catch (tag=12600642,
    func=0x548bd1 <command_loop_2>, arg=12552834) at eval.c:1248
#98 0x0000000000548baa in command_loop () at keyboard.c:1135
#99 0x0000000000548329 in recursive_edit_1 () at keyboard.c:756
#100 0x00000000005484c5 in Frecursive_edit () at keyboard.c:820
#101 0x000000000054666b in main (argc=2, argv=0x7fffffffe708) at emacs.c:1698

Lisp Backtrace:
"scan-sexps" (0xffff35a8)
"byte-code" (0xffff39a0)
"byte-code" (0xffff40c0)
"c-beginning-of-statement-1" (0xffff4908)
"byte-code" (0xffff4d10)
"c-beginning-of-decl-1" (0xffff5488)
"c-font-lock-enclosing-decls" (0xffff5968)
"font-lock-fontify-keywords-region" (0xffff5e68)
"font-lock-default-fontify-region" (0xffff6348)
"font-lock-fontify-region" (0xffff69c0)
"run-hook-with-args" (0xffff69b8)
"byte-code" (0xffff6db0)
"jit-lock-fontify-now" (0xffff7598)
"jit-lock-function" (0xffff7c78)
"redisplay" (0xffffb7b8)
"sit-for" (0xffffbc98)
"isearch-lazy-highlight-new-loop" (0xffffc168)
"isearch-update" (0xffffc648)
"isearch-search-and-update" (0xffffcb18)
"isearch-process-search-string" (0xffffcfd8)
"isearch-process-search-char" (0xffffd4a8)
"isearch-printing-char" (0xffffd980)
"call-interactively" (0xffffdd38)

(gdb) f 4
#4  0x00000000006300a5 in scan_sexps_forward (stateptr=0x7fffffff30b0,
    from=26298, from_byte=48082, end=38471, targetdepth=-10000, stopbefore=0,
    oldstate=12552834, commentstop=0) at syntax.c:3133
3133		      temp = SYNTAX (temp);
(gdb) p temp
$1 = 7077888
(gdb) p from_byte
$2 = 48082
(gdb) p current_buffer->zv
$3 = 41396
(gdb) p current_buffer->zv_byte
$4 = 41396
(gdb) f 5
#5  0x000000000061e721 in back_comment (from=38165, from_byte=38165, stop=1,
    comnested=0, comstyle=0, charpos_ptr=0x7fffffff3418,
    bytepos_ptr=0x7fffffff3420) at syntax.c:733
733		  scan_sexps_forward (&state,
(gdb) p &state
$5 = (struct lisp_parse_state *) 0x7fffffff30b0
(gdb) p defun_start
$6 = 17891
(gdb) p defun_start_byte
$7 = 38163

Message #8 received at 9401 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 9401 <at> debbugs.gnu.org
Subject: Re: bug#9401: 24.0.50; Crash during fontification
Date: Mon, 29 Aug 2011 14:59:36 -0400

> I can trigger this crash about 50 percent of the time by doing
> emacs -q trunk/src/buffer.h
> C-s defvar

> Emacs then crashes with a segfault.

> The problem involves a call to scan_sexps_forward (frame#4) with
> from_byte larger than the byte size of the buffer.

[...]

> #4  0x00000000006300a5 in scan_sexps_forward (stateptr=0x7fffffff30b0,
>     from=26298, from_byte=48082, end=38471, targetdepth=-10000, stopbefore=0,
>     oldstate=12552834, commentstop=0) at syntax.c:3133
> #5  0x000000000061e721 in back_comment (from=38165, from_byte=38165, stop=1,
>     comnested=0, comstyle=0, charpos_ptr=0x7fffffff3418,
>     bytepos_ptr=0x7fffffff3420) at syntax.c:733

There's something pretty fishy going on, indeed, since we end going
"back" from 38165/38165 to 26298/38471, i.e. the char position is
smaller but the byte position is larger.


        Stefan

Message #11 received at 9401 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9401 <at> debbugs.gnu.org
Subject: Re: bug#9401: 24.0.50; Crash during fontification
Date: Mon, 29 Aug 2011 17:16:53 -0400

Here's an additional data point.  Bisection shows that the segfault
(with the given recipe) first shows up with a change to CC mode in July:

  revno: 105278
  committer: Alan Mackenzie <acm <at> muc.de>
  branch nick: trunk
  timestamp: Mon 2011-07-18 17:15:24 +0000
  message:
  CC Mode: Fontify declarators properly when, e.g., a jit-lock chunk begins
  inside a declaration.  Changed cc-engine.el, cc-langs.el, cc-fonts.el.

It seems likely that there is a longer-standing bug in the syntax
handling code which was exposed by this change.

Message #14 received at 9401 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: 9401 <at> debbugs.gnu.org
Subject: Re: bug#9401: 24.0.50; Crash during fontification
Date: Tue, 30 Aug 2011 11:54:40 +0800

FWIW, this crash happens on 23.3.50 too.

Leo

Message #17 received at 9401 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 9401 <at> debbugs.gnu.org
Subject: Re: bug#9401: 24.0.50; Crash during fontification
Date: Tue, 30 Aug 2011 18:45:34 -0400

Chong Yidong <cyd <at> stupidchicken.com> writes:

> I can trigger this crash about 50 percent of the time by doing
>
> emacs -q trunk/src/buffer.h
> C-s defvar
>
> Emacs then crashes with a segfault.
>
> The problem involves a call to scan_sexps_forward (frame#4) with
> from_byte larger than the byte size of the buffer.

I've found the bug, and committed a fix.  It was a problem with
find_defun_start not updating its cache variables consistently.  (Is
that optimization really necessary?  I guess we can re-examine it some
other time.)

Message #22 received at 9401 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 9401 <at> debbugs.gnu.org
Subject: Re: bug#9401: 24.0.50; Crash during fontification
Date: Wed, 31 Aug 2011 08:42:00 -0400

> I've found the bug, and committed a fix.  It was a problem with
> find_defun_start not updating its cache variables consistently.  (Is
> that optimization really necessary?  I guess we can re-examine it some
> other time.)

IIRC this optimization is sometimes important, but it's re-implemented
(in a more sophisticated way) in syntax.el for syntax-ppss, so it would
be good to make the C code somehow use the syntax.el cache.  Maybe the
best way is to change back_comment so that in `lossage' it just calls
a Lisp function (that we'd put in syntax.el), so we can throw away
find_defun_start (and even open_paren_in_column_0_is_defun_start).


        Stefan

Previous Next

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