>
> Hello Folks,
>
> Many folks have experienced this problem, and I think it may have been the
> cause of a couple of complaints here on the list as well.
>
> patchlevel 38, version 2
>
> When fvwm is called as the last thing in the .xinitrc, and in the
> .xinitrc there are a lot of calls to programs which take some time to
> start up, then there seems to be some race condition and some windows
> are not `captured' by fvwm, or get the wrong colour border, or in the worst
> cases, fvwm doesn't work at all and you need to log in else where to kill
> everything off.
>
> I can get around it by either of the following:
> [1] Not making fvwm the last entry in my .xinitrc, and making
> say a console window instead. Of course, this means that I have
> to kill the console window to exit.
> [2] Leaving it as the last entry, but starting up any heavy programs
> via the Init function of .fvwmrc
> This seems to work, and avoid the situation.
>
> I suspect some race condition error in fvwm on start up.
>
> Could somebody else try putting fvwm as last call in .xinitrc
> with 15 "xload &" programs before it :-)
>
[1] doesn't fix it. I call fvwm near the begining of my xsession, but I still
see this. And as for [2], I don't start anything that I consider
heavyweight from either initfunction or .xsession (xterms, xclock, xload, set a
bg pic...).
I mentioned this bug a few weeks ago, but never got a satisfactory answer.
A workaround is not a fix. I see the problem consistantly on our solaris2.4
boxes (with AFS, so that slows things down), and I really can't see pushing
fvwm2 into production in our environment until this is fixed.
No doubt it sucks; race conditions do.
--- Carl
--
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 Fri Oct 27 1995 - 15:10:53 GMT