earle@POSEUR.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) (11/23/89)
>However, the patch in xperfmon.sun4_0.patch in contrib on expo worked just >fine for us (SunOS 4.0.1/3, Sun-4 and SPARCstations). On a totally unrelated note, I have found that `xperfmon' (with the aforementioned patch installed) becomes The Program That Wouldn't Die. If I SIGHUP it, or use `xkill' on it, or hit my `Exit' gadget in my awm titlebar on top of it (f.exit function), etc., the window is unmapped; but the `xperfmon' process itself doesn't exit - it still sits there, and starts to chew up CPU while apparently stuck in the deadly embrace of an ioctl()/select() loop. I have to SIGTERM the bugger to make it go away. Has anyone else noticed this? [ Particulars: Sun-3/260C, SunOS 4.0.3+; all 10 patches applied, ] [ Purdue 2.0 + 2.1, gcc 1.34 compiled; `xperfmon' gcc 1.36 compiled ] -- Greg Earle Sun Microsystems, Inc. - JPL on-site Software Support earle@poseur.JPL.NASA.GOV (direct) earle@Sun.COM (indirect)
peake@inria.inria.fr (Philip Peake) (12/05/89)
earle@POSEUR.JPL.NASA.GOV (Greg Earle) writes: > On a totally unrelated note, I have found that `xperfmon' (with the > aforementioned patch installed) becomes The Program That Wouldn't Die. I've noticed this on our copy. It seems that when the other end of the connection is closed, xperfmon's select() shows the X connection as having something to read (the eof), but it calls XPending() to look for an event, and since this does a ioctl(,FIONREAD,) it finds 0 bytes on the file descriptor, and so goes round the loop again, having done nothing. There are several possible solutions. I just added the following to main_event_loop() in xperfmon.c inside the block after else if (nfound > 0) long num = 0; ioctl (display_fd, FIONREAD, &num); if(num==0)exit(1); You probably need to #include <sys/ioctl.h> -------------- Mark M Martin mmm@cetia.uucp Cetia, Toulon, France mmm@inria!cetia