Subject: FVWM: Serious Erratic Fvwm Bug

From: [email-masked] (Jon Mountjoy)
Date: Fri, 27 Oct 1995 13:49:02 +0100 (MET)

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 :-)

Jon
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: <[email-masked]> (Charles Hines)
Date: Fri, 27 Oct 1995 15:26:37 -0400

>>>>> "Jon" == Jon Mountjoy <[email-masked]> writes:

Jon> Hello Folks,
Jon> Many folks have experienced this problem, and I think it may have
Jon> been the cause of a couple of complaints here on the list as
Jon> well.

Jon> patchlevel 38, version 2

Jon> When fvwm is called as the last thing in the .xinitrc, and in the
Jon> .xinitrc there are a lot of calls to programs which take some
Jon> time to start up, then there seems to be some race condition and
Jon> some windows are not `captured' by fvwm, or get the wrong colour
Jon> border, or in the worst cases, fvwm doesn't work at all and you
Jon> need to log in else where to kill everything off.

Jon> I can get around it by either of the following:
Jon>   [1]  Not making fvwm the last entry in my .xinitrc, and making
Jon>        say a console window instead.  Of course, this means that I have
Jon>        to kill the console window to exit.
Jon>   [2]  Leaving it as the last entry, but starting up any heavy programs
Jon>        via the Init function of .fvwmrc
Jon>        This seems to work, and avoid the situation.

Jon> I suspect some race condition error in fvwm on start up.

Jon> Could somebody else try putting fvwm as last call in .xinitrc
Jon> with 15 "xload &" programs before it :-)

I tried this here (under AIX) and couldn't reproduce any problems.
All 16 xloads came up just ducky.  My suggestions:

  1) What system are you on again (Solaris?) and what compiler (&
     options) did you use to compile fvwm?  If you used gcc, certain
     versions of it are buggy, and if you're using -O3 or higher
     (under whatever compiler) that may be a mistake as well.  Try
     compiling fvwm w/ -g and run it w/ -debug to see if this clears
     anything up.  Also, what does FvwmIdent show for the windows that
     didn't get captured as opposed to those that it did?

  2) If you can't solve it, kick those things off w/ a sleep in front
     of them if they need to be delayed -> (sleep 5; xload &) &
     That way fvwm should start up before they come up, but still be
     the last thing in the .xinitrc.  Or, put a sleep 10 just before
     running fvwm, to give everything time to come up first.  Most
     sample .xinitrc files seem to do this for everything, so this may
     be a potential problem with all window managers.

The only potential problems I can see is if one of the windows happens
to be coming up while fvwm is traversing the window list capturing the
windows (so it wouldn't be in the window list) and didn't get a
notification that a new window appeared (why, I don't know).  I'll
look through the code and see if there is anything glaring (which I
doubt - if there is a bug it'll be a subtle one).

Also, I imagine that a 'Recapture' should pick those windows up again.

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis developer [BooleDozer (TM)]
and Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

IBM Internal email: [email-masked],
                    HINESC at FISHKILL, HINESC at FSHVMFK1

 "I have a paper plate in my head because they were all out of the metal ones"
                                                        - Rick Overton
*******************************************************************************
--
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Carl A. Adams" <[email-masked]>
Date: Fri, 27 Oct 1995 16:10:38 -0400

> 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