Re: crash when opening a newsgroup

[Timmy Douglas]

Richard Stallman <address@hidden> 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...