Re: Emacs core dump

[Cyprian Laskowski]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Since Emacs 20.3 is quite old and had known bugs, could you try
> upgrading to v20.7 on that machine?
> 

Probably not, since this version is on a system with overworked
sysadmins who think that I'm nuts when it comes to Emacs (no doubt
they are correct).  But my home problems are occurring on v20.7, so
I'm not sure that would help.  Also, other people at work using the
same Emacs are not having crashes.

> Do you remember what were you doing when these craashes happened?

Well, that's the interesting thing.  They seem to happen in all kinds
of different contexts, making it seem like a low-level thing which is
just waiting to get stimulated in the wrong way and bring things down
with itself.

The crashes often seem to occur during the loading of a big package or
the execution of a command.  But these packages differ from crash to
crash, and the crashes are not (as far as I can tell) reproducible.
For example, sometimes Emacs crashes while I'm loading gnus (I think
sometimes during loading of gnus-summary).  But sometimes it crashes
in sessions where gnus hasn't even been loaded at all.

And there are also times when I'm doing something very innocent, like
opening a file or even just typing, and it'll crash.  In fact, once or
twice it even crashed overnight (I left in running when I came from
work, and the next morning I came and it was gone, having crashed).

One thing I can say is that usually I can tell when the crash is about
to happen (about a second or so beforehand), because Emacs pauses
unreasonably at the execution of something that doesn't normally take
so long.  For example, I could type M-x eshell RETURN, and the
*eshell* buffer won't appear immediately, and "M-x eshell" will remain
in the minibuffer, and then half a second later, BOOM!  And this is on
a local machine which wouldn't hang like that I think for a network
reason.  Maybe if I'm quick and alert enough, I could switch to an
xterm at such a moment which has a gdb already running and attached to
the emacs PID (can it be attached while I'm screwing around in it),
and I could have "signal STOP" or whatever just awaiting me to press
<RETURN> and then I could do something useful there ("useful" as
defined by you)?  I don't know if that makes any sense, and I would
have to be very quick indeed.

Once I ran top and found that my Emacs session was the second biggest
(right after a Cold Fusion server) process in size (18 MB I think) on
a fairly big multi-user system.  Other emacs users had Emacses of just
a couple of MBs.  I'm not surprised that mine would be much bigger
because I keep it running longer (until it crashes!) and I load a lot
more stuff, but still: is 18 MB normal for heavy duty Emacs users?

I wonder if there might be some system-wide constraints (perhaps
applied both at work and by default at home) on how much resources are
provided to an instance of programs like Emacs, and so forth.  I don't
know what I'm talking about here, but might it be useful to try to
screw with things like "nice" to increase the "nice" level of Emacs?

If this problem is too deep or vague for you to help me with further
debugging, then I would really appreciate some "best worst case
advice".  For example, I'm slowly trying to comment out my Emacs
extensions, in the hopes of finding the one that is pulling the
trigger, if there is such a one.  Does this seem like a good idea, or
is it bound for failure from scratch because the problem is more
likely to be the conflicting of two or more different packages, rather
than any one in particular?  Would it help to try to get my hands on
Emacs 21 (how can I do this?), and hope that the problem is solved by
chance there?

Should I keep posting backtraces and xbacktraces?

Thanks again and sorry for the long spiel,

cyp