🚀 go-pugleaf

In article <41865@cornell.UUCP>, deb@elli (David Baraff) writes:
 |We're running 7.0 on an 835, using X11R4.
 |
 |Has anyone noticed gnuemacs hanging around after X exits?
 |I logged on today and found a gnuemacs burning cycles.
 |
 |We're using a standard 18.55 version of gnuemacs, with the
 |new process.c that someone posted to this group.
 |
I also noticed problems with emacs/X11R4. We have 9000/340 workstations. I
have noticed emacses burning cycles, but can't remember whether that was
the X11R4 version. 

I have the version with additional patches for handling of interrupts (posted
by myself).

Another problem that I had was emacs using up all memory, and the
generating a core dump. I tracked the problem down to a malloc() call in
XEnq or something similar, which returned NULL, after which XEnq called
abort().
The first time I had this problem was when our server had died, and all
workstations booted at the same time. Starting emacs took a long time and
when I shuffeled something with thge windows during initialization, emacs
died with the problem mentioned above. Besides that I got a message on my
screen about a kernel problem !!
Later, I was able to reconstruct the first problem by starting emacs and
then switching windows rapidly (with an overlapping window). A collegue of
mine had similar problems, just when he started emacs. But he used mwm,
while I use twm.

I reverted to X11R3, and haven't got any problems since.

One thing I don't trust is the malloc()/free(). The emacs malloc is written
reentrantly, but the free is not. I can imagine situations where a free in
the main program is interrupted by a free or malloc in a signal handler.
The odds are small of course, but it could happen.
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31-30-513791   Internet:  piet@cs.ruu.nl   (*`Pete')