deb@elli.cs.cornell.edu (David Baraff) (06/07/90)
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. If you have any idea how to fix things so gnuemacs will die after X dies, please, please let me know. David Baraff deb@cs.cornell.edu
piet@cs.ruu.nl (Piet van Oostrum) (06/08/90)
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')