Re: Ediff frequently crashes emacs.

[Peter Seibel]

address@hidden (Kim F. Storm) writes:

> Peter Seibel <address@hidden> writes:
>
>> address@hidden (Kim F. Storm) writes:
>>
>>> What happens if you don't use byte-compiled ediff? Try adding this
>>> to your .emacs and rerun the test:
>>>
>>> (load "ediff-init.el")
>>> (load "ediff-diff.el")
>>
>> So, by chance or not, it crashed almost right away after I started
>> using ediff with those two lines in my .emacs.
>
> Very odd!

FWIW, the next time I started it up with those lines still in my
.emacs it ran fine, for a while anyway.
>
>> Program received signal SIGSEGV, Segmentation fault.
>> x_catch_errors_unwind (old_val=137240633) at xterm.c:7514
>> 7514   Display *dpy = XSAVE_VALUE (first)->pointer;
>> (gdb) bt
>> #0  x_catch_errors_unwind (old_val=137240633) at xterm.c:7514
>> #1  0x08130317 in unbind_to (count=63, value=137240609) at eval.c:3146
>> #2  0x08154749 in Fbyte_code (bytestr=135923915, vector=135924068, 
>> maxdepth=5)
>>     at bytecode.c:885
>
> This happens in 
>
>      case Btemp_output_buffer_show:
>
> which expects to unbind a binding created by a previous
>
>      case Btemp_output_buffer_setup:
>
> but finds something different on the binding stack.
>
>>From the backtrace stack, I cannot see any reason why
> either of with-output-to-temp-buffer or x_catch_errors
> should be active, so this looks really odd.
>
> Could be a byte-compiler error (but then I guess ediff would never
> work), or a side-effect of memory trashing like the other traps you
> have seen. We "just" have to identify what part of the code is
> trashing the memory.
>
>
>> (gdb) xbacktrace
>> "backquote-listify"
>> "backquote-process"
>> "backquote-process"
>> "backquote-process"
>> 0x81a04e4 PVEC_COMPILED
>> "`"
>> 0x8b65b35 Lisp type 5
>> "ediff-get-difference"
>> "aref"
>
> ..
>
> I don't know where the "Lisp type 5" thing (a cons cell) came from
> either, but this is quite deeply nested macros using backquote, so it
> could be something I just don't understand...
>
> Please continue to send traps.

Okay, here's another strange one which has happened a few times. I'll
get an error in the minibuffer that says:

  Symbol's value as variable is void: nil

No matter what I do I continue to get that error or something similar
such as:

  Error in pre-command-hook: (void-variable nil)

I can type 'q' to the ediff window and it'll ask if I want to quit but
when I type 'y' it goes back to:

  Symbol's value as variable is void: nil

I realize that this is probably just more symptoms of memory
corruption but maybe one of these details will give someone an aha
moment. (BTW, is there a way to interrupt emacs without killing it so
I can get a backtrace from GDB?)

-Peter

-- 
Peter Seibel                                     address@hidden

         Lisp is the red pill. -- John Fraser, comp.lang.lisp