For me (2.0.41 on linux) it is not an old fvwm2 process, but the
current one, that zooms up to load 1.0 until I restart fvwm2. This
happens quite frequently. Now, I faily often kill and start a module
(in this case tkgoodstuff, which runs as a module using tkfvwm). This
may have something to do with it, but fvwm2's load doesn't go down
when the module is killed. (Could it be something about paying
respects to dead modules?) Since I produce this effect pretty
reliably (twice this afternoon), I'd be happy to do a little
debugging, if told what to do...
Chris Rode wrote:
>Mark Naumann <rysw20_at_email.mot.com> wrote:
>}When fvwm does not exit, it goes into some runaway mode. The next time I
>}login, my .xsession starts a new fvwm process. Now I have one runaway (from
>}previous login) and this new fvwm process. If I don't manually kill the old
>}process, it just sits there consuming CPU cycles (and upsets a lot of my
>}colleagues!)
>i also get this, but it isn't sporadic -- it happens all the time if i
>don't explicitly quit fvwm. this is happening to everyone that i know
>of using the copy of fvwm2 i compiled. most, myself included, have made
>fvwm our session manager, thus eliminating the problem by forcing us to
>quit fvwm before logging out. if not explicitly killed, the process
>hangs around, and the load sits at a constant 1.0 until the process is
>killed off. I'm using fvwm 2.0.41 under ultrix 4.3, osf/1 3.2, and irix
>5.3.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Mar 28 1996 - 15:07:55 GMT