bug#1380: 23.0.60; file content causes CVS emacs to crash

bug#1380: 23.0.60; file content causes CVS emacs to crash

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The file content in a file causes Emacs to crash as soon as it's opened.
Tested with "emacs -q file".  This is a vimrc file, but it causes the
crash under any name, so it's content-related and not mode-related.  I
can't attach the file directly because doing so crashes Emacs; I am
attaching it compressed.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/local/share/emacs/23.0.60/etc/DEBUG for instructions.

#0  0xb7fe3410 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb76634b6 in kill () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2  0x081075d2 in fatal_error_signal (sig=0xb) at emacs.c:399
No locals.
#3  <signal handler called>
No symbol table info available.
#4  0x0818769d in print_object (obj=0x1, printcharfun=0x8369d49, escapeflag=0x1) at print.c:1731
        end = <value optimized out>
        c = <value optimized out>
        i_byte = <value optimized out>
        confusing = <value optimized out>
        p = <value optimized out>
        size_byte = <value optimized out>
        buf = "��9\b\002\000\000\000\000\000\n�I\2356\b\001\000\000\000I\2356\b\001\000\000\000I\2356\b\001\000\000\000z?:\b"
#5  0x0818bc5d in Fprin1 (object=0x1, printcharfun=0x8369d49) at print.c:750
        old = (struct buffer *) 0x8370218
        old_point = 0xffffffff
        start_point = 0xffffffff
        old_point_byte = 0xffffffff
        start_point_byte = 0xffffffff
        free_print_buffer = 0x0
#6  0x0818c19a in print_error_message (data=0x8d18dad, stream=0x8369d49, context=0xbfffedc6 "", caller=0x8391d91) at print.c:1105
        obj = 0x0
        errname = 0x83745f9
        errmsg = 0x838aad3
        file_error = 0x8369d19
        tail = <value optimized out>
        i = 0x1
#7  0x08110c8e in cmd_error_internal (data=0x8d18dad, context=0xbfffedc6 "") at keyboard.c:1283
No locals.
#8  0x08110d95 in cmd_error (data=0x8d18dad) at keyboard.c:1222
        old_level = 0x8369d19
        old_length = 0x8369d19
        macroerror = "\000���\004\b\000\000\000\000����@���\000\000\000\000\000\000��\031\2356\b��\205\b\000\000\n�\000\000\000\000\020\237>\b\000\237>\b"
#9  0x0816f3bc in internal_condition_case (bfun=0x810d300 <top_level_2>, handlers=0x83745c9, hfun=0x8110ce0 <cmd_error>) at eval.c:1501
        val = <value optimized out>
        c = {tag = 0x8369d19, val = 0x8d18dad, next = 0xbfffef30, gcpro = 0x0, jmp = {{__jmpbuf = {0x0, 0x83e9f10, 0x83e9f00, 0xbfffeef8, 0xebdc2081, 0x39e6a3ee}, __mask_was_saved = 0x0, __saved_mask = {__val = {0xb7643b1c, 0xbfff0002, 0xb7ff2259, 0x804ecee, 0xb78eacd4, 0xb7ffeff4, 0xbfffed50, 0xb73bf620, 0xbfffed84, 0xb7fed059, 0x8c2d778, 0xbfffed44, 0xb7782ff4, 0x8c2d778, 0xb7ffb5bc, 0xbfffed50, 0xbfffee50, 0xbfffeeb0, 0xbfffefd0, 0xffffffff, 0xbfffef38, 0x811f6c3, 0xbfffefd0, 0xb763fb9c, 0xb78ead20, 0x0, 0xffffffff, 0xb7ffeff4, 0x804a758, 0xb7fff668, 0xbfffef00, 0xb7ff1429}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0x0, pdlcount = 0x2, poll_suppress_count = 0x1, interrupt_input_blocked = 0x0, byte_stack = 0x0}
        h = {handler = 0x83745c9, var = 0x8369d19, chosen_clause = 0x8369d49, tag = 0xbfffee1c, next = 0x0}
#10 0x08110a80 in top_level_1 () at keyboard.c:1355
No locals.
#11 0x0816f46a in internal_catch (tag=0x8373611, func=0x8110a50 <top_level_1>, arg=0x8369d19) at eval.c:1247
        c = {tag = 0x8373611, val = 0x8369d19, next = 0x0, gcpro = 0x0, jmp = {{__jmpbuf = {0x0, 0x83e9f10, 0x83e9f00, 0xbfffeff8, 0xebde4081, 0x39e8bbee}, __mask_was_saved = 0x0, __saved_mask = {__val = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xb76a3d91, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8c52328, 0xb77652f5, 0x0, 0xb7784190, 0x0, 0x83a4022, 0x83a4648, 0x83a4020, 0xbfffefe8, 0x8160f75, 0x83a4649, 0x83a4022, 0x8369d19, 0x8370218, 0x0, 0x0, 0x8369d31}}}}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0x0, pdlcount = 0x2, poll_suppress_count = 0x1, interrupt_input_blocked = 0x0, byte_stack = 0x0}
#12 0x08110b29 in command_loop () at keyboard.c:1310
No locals.
#13 0x08110ebb in recursive_edit_1 () at keyboard.c:942
        val = <value optimized out>
#14 0x08110ff1 in Frecursive_edit () at keyboard.c:1004
        buffer = 0x8369d19
#15 0x081068d5 in main (argc=0x3, argv=0xbffff3f4) at emacs.c:1777
        dummy = 0x0
        stack_bottom_variable = 0x8
        do_initial_setlocale = <value optimized out>
        skip_args = 0x0
        rlim = {rlim_cur = 0x800000, rlim_max = 0xffffffffffffffff}
        no_loadup = 0x0
        junk = 0x0
        dname_arg = 0x0

In GNU Emacs 23.0.60.24 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2008-11-17 on tzlatanov-ubuntu-desktop
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--without-makeinfo' 'CC=gcc''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t


[-- Attachment #2: v.gz --]
[-- Type: application/octet-stream, Size: 5587 bytes --]

bug#1380: 23.0.60; file content causes CVS emacs to crash

[Chong Yidong]

> The file content in a file causes Emacs to crash as soon as it's
> opened.  Tested with "emacs -q file".

Looks like the charbuf in the coding structure is overflowing.  The
following rough patch prevents this overflow and the crash, but maybe
there is a deeper bug.  The comments in coding.c:6610 says "We are sure
that the number of data is less than the size of coding->charbuf."  This
bug comes about due to that faile assumption.

Handa-san, what do you think?

*** trunk/src/coding.c.~1.394.~	2008-10-24 00:06:43.000000000 -0400
--- trunk/src/coding.c	2008-11-20 02:29:02.000000000 -0500
***************
*** 6617,6622 ****
--- 6617,6633 ----
  
  	      if (c & 0x80)
  		c = BYTE8_TO_CHAR (c);
+ 
+ 	      if (coding->charbuf_used >= coding->charbuf_size)
+ 		{
+ 		  int *old_charbuf = coding->charbuf;
+ 
+ 		  coding->charbuf_size *= 2;
+ 		  coding->charbuf = (int *) alloca (sizeof (int)
+ 						    * coding->charbuf_size);
+ 		  bcopy (old_charbuf, coding->charbuf, coding->charbuf_size);
+ 		}
+ 
  	      coding->charbuf[coding->charbuf_used++] = c;
  	    }
  	  produce_chars (coding, Qnil, 1);

bug#1380: 23.0.60; file content causes CVS emacs to crash

[Kenichi Handa]

In article <87myfuhmrk.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> > The file content in a file causes Emacs to crash as soon as it's
> > opened.  Tested with "emacs -q file".

> Looks like the charbuf in the coding structure is overflowing.  The
> following rough patch prevents this overflow and the crash, but maybe
> there is a deeper bug.  The comments in coding.c:6610 says "We are sure
> that the number of data is less than the size of coding->charbuf."  This
> bug comes about due to that faile assumption.

> Handa-san, what do you think?

I found that it's a bug in detect/decode_coding_iso_2022,
and just installed a fix.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: bug#1380: 23.0.60; file content causes CVS emacs to crash

[Ted Zlatanov]

On Fri, 21 Nov 2008 11:25:07 +0900 Kenichi Handa <handa@m17n.org> wrote: 

KH> In article <87myfuhmrk.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:
>> > The file content in a file causes Emacs to crash as soon as it's
>> > opened.  Tested with "emacs -q file".

>> Looks like the charbuf in the coding structure is overflowing.  The
>> following rough patch prevents this overflow and the crash, but maybe
>> there is a deeper bug.  The comments in coding.c:6610 says "We are sure
>> that the number of data is less than the size of coding->charbuf."  This
>> bug comes about due to that faile assumption.

>> Handa-san, what do you think?

KH> I found that it's a bug in detect/decode_coding_iso_2022,
KH> and just installed a fix.

Fix confirmed here.

Thanks
Ted

Re: bug#1380: 23.0.60; file content causes CVS emacs to crash

[Ted Zlatanov]

On Fri, 21 Nov 2008 12:41:43 -0600 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Fri, 21 Nov 2008 11:25:07 +0900 Kenichi Handa <handa@m17n.org> wrote: 
KH> In article <87myfuhmrk.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:
>>> > The file content in a file causes Emacs to crash as soon as it's
>>> > opened.  Tested with "emacs -q file".

>>> Looks like the charbuf in the coding structure is overflowing.  The
>>> following rough patch prevents this overflow and the crash, but maybe
>>> there is a deeper bug.  The comments in coding.c:6610 says "We are sure
>>> that the number of data is less than the size of coding->charbuf."  This
>>> bug comes about due to that faile assumption.

>>> Handa-san, what do you think?

KH> I found that it's a bug in detect/decode_coding_iso_2022,
KH> and just installed a fix.

TZ> Fix confirmed here.

When I tried to commit the file discussed in the original bug report to
a CVS repository, Emacs crashed with a segfault.  The file was
committed, so this happened after the cvs executable was called.  I
didn't do a thorough debugging session because this is very likely to be
a proliferation of the same bug, but if you can't duplicate it I will
produce a backtrace, etc.

Thanks
Ted