Richard Stallman <[EMAIL PROTECTED]> writes: > Side note: one thing that would be nice is if emacs would always crash > instead of aborting...sometimes I run it outside of gdb and > aborting is like exiting cleanly (I think?) so there is no way > to figure out what went wrong. > > I don't really understand that; I am not sure what you mean by > "crash instead of aborting" or why you think that this affects > whether you can figure out what went wrong. Are you saying > you want it to make a core dump? > > `abort' causes a fatal signal. It ought to make a core dump > if you have enabled core dumps.
ok, if this is the case then don't worry about it. I just remember not running emacs from gdb before and then it aborted without leaving behind a core file. I guess I didn't have core dumps enabled. > Anyway, that backtrace looks really bizarre. It seems that the stack > has somehow been completely corrupted. It makes no sense for > funcall_lambda to have called send_process. But it is not > entirely nonsense; for instance, Ffuncall really does call > funcall_lambda. If something was using a foreign function call out to C land maybe? I don't know. > send_process really does call error, but the first argument > is always a string constant, so it is strange that you > get nonexistent memory addresses. > > I can't figure out any more than this. I'm not really clear on this and it's probably not worth looking at, but I have a theory that gdb somehow latched onto an emacs process that was run from the same xterm window, but gdb didn't have permissions to look at its memory. But I don't know enough about gdb/etc to know if that's possible. Anyways, we probably shouldn't worry about this one... _______________________________________________ Emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
