Re: Ediff frequently crashes emacs.

[Kim F. Storm]

Peter Seibel <address@hidden> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0420824ed in bcopy () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0x420824ed in bcopy () from /lib/i686/libc.so.6
> #1  0x0804ff39 in safe_bcopy (from=0x9c2ea64 "C#\032\b\350\371\373\t\b", 
>     to=0x989dad8 "h*S\t", size=156445280) at dispnew.c:490

That size is completely bogus.  It looks more like a pointer than a length.
And it definitely cannot be the size of a small string.

We have this code:

      if (from->string)
        nbytes = GC_STRING_BYTES (from->string);
      else
        nbytes = SDATA_NBYTES (from);


Perhaps a previous string element was written after the end (with NULs), thus
clearing the from->string element, causing the from->u.data to be interpreted
as from->u.nbytes.

Alternatively, the from->string itself has been overwritten.

But where ?


> #2  0x0812c6a8 in compact_small_strings () at alloc.c:1895
> #3  0x0812fa0b in gc_sweep () at alloc.c:5224
> #4  0x0812ea7d in Fgarbage_collect () at alloc.c:4551
> #5  0x08168969 in Fbyte_code (bytestr=138113611, vector=139498588, 
> maxdepth=96)
>     at bytecode.c:523
> #6  0x081428a3 in funcall_lambda (fun=139909676, nargs=2, 
>     arg_vector=0xbfffef44) at eval.c:2944
> #7  0x08142479 in Ffuncall (nargs=3, args=0xbfffef40) at eval.c:2814
> #8  0x08168b78 in Fbyte_code (bytestr=139501523, vector=139434196, 
> maxdepth=48)
>     at bytecode.c:686
> #9  0x081428a3 in funcall_lambda (fun=139685772, nargs=1, 
>     arg_vector=0xbffff074) at eval.c:2944
> #10 0x08142479 in Ffuncall (nargs=2, args=0xbffff070) at eval.c:2814
> #11 0x08168b78 in Fbyte_code (bytestr=140692387, vector=139886644, 
> maxdepth=32)
>     at bytecode.c:686
> #12 0x081428a3 in funcall_lambda (fun=140594556, nargs=1, 
>     arg_vector=0xbffff1c4) at eval.c:2944
> #13 0x08142479 in Ffuncall (nargs=2, args=0xbffff1c0) at eval.c:2814
> #14 0x0813eda1 in Fcall_interactively (function=140305409, 
>     record_flag=17165666, keys=137382204) at callint.c:877
> ---Type <return> to continue, or q <return> to quit---
> #15 0x080f1f59 in Fcommand_execute (cmd=140305409, record_flag=137325329, 
>     keys=137325329, special=137325329) at keyboard.c:9679
> #16 0x080e82f3 in command_loop_1 () at keyboard.c:1779
> #17 0x081408ea in internal_condition_case (bfun=0x80e7420 <command_loop_1>, 
>     handlers=137386297, hfun=0x80e6f9c <cmd_error>) at eval.c:1367
> #18 0x080e7292 in command_loop_2 () at keyboard.c:1309
> #19 0x08140483 in internal_catch (tag=137380321, 
>     func=0x80e7274 <command_loop_2>, arg=137325329) at eval.c:1128
> #20 0x080e7221 in command_loop () at keyboard.c:1288
> #21 0x080e6d53 in recursive_edit_1 () at keyboard.c:981
> #22 0x080e6e7b in Frecursive_edit () at keyboard.c:1042
> #23 0x080e5cdf in main (argc=3, argv=0xbffff984) at emacs.c:1736
> #24 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
> (gdb) xbacktrace
> "ediff-make-fine-diffs"
> "ediff-install-fine-diff-if-necessary"
> "ediff-next-difference"
> "call-interactively"
> (gdb) xtype
> The history is empty.
> (gdb) 
>
>
> -Peter
>
> -- 
> Peter Seibel                                      address@hidden
>
>          Lisp is the red pill. -- John Fraser, comp.lang.lisp
>
>
> _______________________________________________
> Emacs-pretest-bug mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
>
>

-- 
Kim F. Storm <address@hidden> http://www.cua.dk