Subject: FvwmWinList.c : experimental fix

From: Chris Rankin <[email-masked]>
Date: Fri, 22 Jan 1999 23:00:16 -0500 (EST)

Hi,
I have examined the select() in FvwmWinList and have created the
following diff. Can anyone who has trouble with FvwmWinList test this
patch out, please? For extra credit, can you try it both with and
without the new XFlush() calls in fvwm2 as well? The calls to XFlush
worry me because I think this would allow a slow module to miss
events.

Cheers,
Chris.

--- FvwmWinList.c.orig	Fri Jan 22 22:51:10 1999
+++ FvwmWinList.c	Fri Jan 22 22:55:06 1999
@@ -238,6 +238,14 @@
 fd_set readset;
 
   while( !isTerminated ) {
+
+    /*
+     * If there are events in the queue then do nothing,
+     * otherwise read events from the XServer and put them
+     * into the input queue.
+     */
+    XPending(dpy);
+
     FD_ZERO(&readset);
     FD_SET(Fvwm_fd[1],&readset);
     FD_SET(x_fd,&readset);
@@ -248,7 +256,7 @@
      */
     if (select(fd_width,SELECT_TYPE_ARG234 &readset,NULL,NULL,NULL) > 0) {
 
-      if (FD_ISSET(x_fd,&readset) || XPending(dpy)) LoopOnEvents();
+      if (FD_ISSET(x_fd,&readset)) LoopOnEvents();
       if (FD_ISSET(Fvwm_fd[1],&readset)) ReadFvwmPipe();
 
     }
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Sat, 23 Jan 1999 16:59:16 -0500

> worry me because I think this would allow a slow module to miss

Well, I  have to start by saying,  my bug report was  pretty bad  so I
want to clear it up.

For some reason, I start FvwmWinList like this:

AddToFunc ConfigWinList "I" module FvwmWinList
+                       "I" Recapture

AddToMenu "Modules" "%mini.window.xpm%&WinList"	ConfigWinList

So something  hangs, but I can't say  if its FvwmWinList or Recapture,
or the  combination of both.    What I see  when it  does  hang is  an
incomplete Recapture and FvwmWinList hasn't appeared yet.

I was able  to  get  the FvwmWinList  plus  Recapture to  hang   after
applying the  FvwmWinList  patch  from Chris.   A number  of  attempts
failed  until I created about  10 windows.   Even  then it wasn't very
consistent.  (Once out of 5 tries so far.)

So  far, I  haven't  seen any  hang  trying  just FvwmWinList  or just
Recapture.

I haven't tried the extra credit XFlush() yet.

I'm pretty sure I've seen this symptom in releases long before 2.0.46.
I've always started FvwmIconBox like this:

AddToFunc ConfigIconBox "I" module FvwmIconBox
+                       "I" Style     "*"  NoIcon
+                       "I" Recapture

In this case, the Recapture makes sense, and I'm pretty sure it hung
on occasion, although right now it won't.  So I think this may not
be a new problem.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Chris Rankin <[email-masked]>
Date: Sat, 23 Jan 1999 19:49:28 -0500 (EST)

> incomplete Recapture and FvwmWinList hasn't appeared yet.

What platform are you using? CPU type and speed? libc.so.? OS? I have
created a ConfigWinList function of my own and haven't been able to
reproduce the hang yet. The intermittent nature of the problem
suggests a race condition of some sort.

Cheers,
Chris.

---

From: Dan Espen <[email-masked]>
Date: Sun, 24 Jan 1999 00:08:58 -0500

> suggests a race condition of some sort.

This doesn't look like it has anything to do with FvwmWinList.

I got a stack trace while fvwm2 was hung:

(gdb) where
#0  0xef5e87e8 in _libc_read ()
#1  0x4e36c in PositiveWrite (module=0, ptr=0xefffe8f0, size=60)
    at ../../version-2_1_11/fvwm/module.c:643
#2  0x4d940 in BroadcastPacket (event_type=256, num_datum=11)
    at ../../version-2_1_11/fvwm/module.c:452
#3  0x3e904 in Iconify (tmp_win=0xf62d8, def_x=-1, def_y=-1)
    at ../../version-2_1_11/fvwm/icons.c:964
#4  0x348b8 in HandleMapRequestKeepRaised (KeepRaised=0)
    at ../../version-2_1_11/fvwm/events.c:816
#5  0x39388 in CaptureAllWindows () at ../../version-2_1_11/fvwm/fvwm.c:676
#6  0x2e9c8 in Recapture (eventp=0x77ff0, junk=12583358, tmp_win=0xde7e8,
    context=64, action=0xe5cf1 "", Module=0xefffed8c)
    at ../../version-2_1_11/fvwm/builtins.c:4656
#7  0x379a0 in ExecuteFunction (Action=0xe5c70 "Recapture", tmp_win=0xde7e8,
    eventp=0x77ff0, context=64, Module=-2)
    at ../../version-2_1_11/fvwm/functions.c:265
#8  0x30728 in ComplexFunction (eventp=0x77ff0, w=12584565, tmp_win=0xde7e8,
    context=64, action=0xe5c35 "", Module=0xefffef84)
    at ../../version-2_1_11/fvwm/complex.c:122
#9  0x379dc in ExecuteFunction (Action=0x92d00 "ConfigWinList",
    tmp_win=0xde7e8, eventp=0x77ff0, context=64, Module=-1)
    at ../../version-2_1_11/fvwm/functions.c:271
#10 0x3f2a4 in do_menu (menu=0xbdbb0, menuPrior=0x0,
    pmiExecuteAction=0xeffff058, cmenuDeep=0, fStick=0, eventp=0x1,
    pops=0xeffff040) at ../../version-2_1_11/fvwm/menus.c:275
#11 0x2354c in menu_func (eventp=0x77ff0, w=12584574, tmp_win=0xde7e8,
    context=64, action=0x0, Module=0xeffff1f4, fStaysUp=0)
    at ../../version-2_1_11/fvwm/builtins.c:1069
#12 0x235d0 in popup_func (eventp=0x77ff0, w=12584574, tmp_win=0xde7e8,
    context=64, action=0xe5c46 "Utilities", Module=0xeffff1f4)
    at ../../version-2_1_11/fvwm/builtins.c:1080
#13 0x379a0 in ExecuteFunction (Action=0xc2210 "Popup Utilities",
    tmp_win=0xde7e8, eventp=0x77ff0, context=64, Module=-1)
    at ../../version-2_1_11/fvwm/functions.c:265
#14 0x3362c in HandleKeyPress () at ../../version-2_1_11/fvwm/events.c:399
#15 0x32d10 in DispatchEvent () at ../../version-2_1_11/fvwm/events.c:156
#16 0x32d78 in HandleEvents () at ../../version-2_1_11/fvwm/events.c:184
#17 0x38d7c in main (argc=1, argv=0xeffff794)
    at ../../version-2_1_11/fvwm/fvwm.c:521
(gdb)

Its interesting to note that both Recapture() builtins.c:4656 and
CaptureAllWindows() fvwm.c:676 call MyGrabServer.  It looks like
the server is grabbed by fvwm2 for the duration of a recapture.

During  recapture processing,   windows  get iconified.   If you  have
FvwmAnimate running,    like  I    do,   fvwm2  attempts   synchronous
communications   with   FvwmAnimate.  When    FvwmAnimate gets Iconify
messages, it attempts to grab the server.

It seems to me like thats enough to explain the hang.

I'm not sure why  recapture needs a  server grab, why it  doesn't hang
every  time, why windows  are   iconified during recapture  (they  are
already iconified).

Back to the code.  Oh, its midnight.  How am I going to sleep with
this one still unresolved?  Not well.

---

From: Bob Woodside <[email-masked]>
Date: Sun, 24 Jan 1999 00:42:29 -0500 (EST)

Dan Espen <[email-masked]> wrote:
> 
> It looks like the server is grabbed by fvwm2 for the duration of
> a recapture....  During  recapture processing,   windows  get
> iconified.... When FvwmAnimate gets Iconify messages, it attempts
> to grab the server.

	Ouch!

> I'm not sure why  recapture needs a  server grab,

	Well, it's reparenting all the windows back to root, and then
reparenting them all back to itself again.

> why it  doesn't hang every  time,

	Is a puzzlement....

> why windows are iconified during recapture (they are already
> iconified).

	This may be an artifact from a time before there was a Re-
capture, when this code was only used at startup and restart. When
we reparent back to root, we deiconify iconified windows. Hmm...
you're right, it's too late to follow this train of thought too far
right now.

- Bob

---

From: [email-masked] (Paul D. Smith)
Date: 24 Jan 1999 01:13:40 -0500

These kinds of problems are definitely too involved to resolve before
2.2 goes out.

What we need to decide is if there are issues with the new signal
handling of FvwmWinList such that we would be better off with the old
code.  The core dump problem has been resolved.  What about the other
problems Tim et. al. were seeing?  Are these "known" problems, or new
(Tim seemed to think they were new)?  Are they fixed (insofar as they
worked before) by Chris's suggested changes?

What's the best way to move forward to releasing 2.2 ASAP?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Chris Rankin <[email-masked]>
Date: Sun, 24 Jan 1999 09:36:03 -0500 (EST)

> code.

Well, from my perspective, the signal handling strategy is the same
across all the modules I've tinkered with - it "bugs" me to hear
reports of problems in just one module. Not that I'm eager to hear of
core-dumps in everything else either ... :-)

However, there's another (unrelated) tweak I'd like to make to both
FvwmWinList and FvwnIconMan, but I can't post the patch until this
matter is satisfactorily resolved. Which reminds me, the "experimental
fix" for FvwmWinList needs applying to FvwmIconMan too.

On an (apparently? ;-)) unrelated note, is there a standard MAX(a,b)
macro already provided by FVWM? I know it's totally trivial to write,
but why duplicate code?

Cheers,
Chris.

---

From: Dan Espen <[email-masked]>
Date: Sun, 24 Jan 1999 10:39:43 -0500

> you're right, it's too late to follow this train of thought too far

After sleeping on it, the fix I've come up with is,

1. Change the grab count in libs/Grab.c to an extern.
2. In modules.c, if broadcasting M_ICONIFY to a lockonsend
module and the grabcount is not zero, don't send anything.

It seems to  me like a fairly  safe change.  Since its  for lockonsend
modules only, it could  only break FvwmAnimate,  and then, only if the
grabcount is off.

I won't commit anything without agreement.

---

From: Bob Woodside <[email-masked]>
Date: Sun, 24 Jan 1999 15:58:54 -0500 (EST)

> I won't commit anything without agreement.

	This sounds good to me. Nobody really needs to know about the
Iconify, because we aren't actually changing the position or iconic state
of the windows during a Recapture - they're going to end up just like
they were. But, just to be safe, limiting this to lockonsend modules
sounds like a good idea.

- Bob

---

From: Steve Robbins <[email-masked]>
Date: Sun, 24 Jan 1999 23:59:13 -0500 (EST)

> macro already provided by FVWM? I know it's totally trivial to write,

Yes.  It is called "max" ("min" also exists).  Look in acconfig.h; this
code ends up in config.h, so you have max, min, and abs as long as you
#include "config.h".

--
Steve Robbins                              <[email-masked]>

Too cool to live -- too smart to die.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 25 Jan 1999 13:35:29 +0000

> +      if (FD_ISSET(x_fd,&readset)) LoopOnEvents();

This fixes my problems with FvwmWinlist not following focus changes.
This is without the extra Xflush calls in fvwm2.

Cheers,
Tim.

---

From: Chris Rankin <[email-masked]>
Date: Mon, 25 Jan 1999 08:49:47 -0500 (EST)

> This is without the extra Xflush calls in fvwm2.

Great! Just as a matter of interest, though: did you ever see a
similar problem with FvwmIconMan? Because that's where the broken
event-loop code was lifted from. (I'll create a patch for FvwmIconMan
too)

Cheers,
Chris.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 25 Jan 1999 13:51:46 +0000

> module and the grabcount is not zero, don't send anything.

FvwmIconMan, FvwmWinList and FvwmButtons also call XGrabserver, the
first two do it as part of the growing upwards stuff.  They both go wild
during a recapture and so there probably is a danger of one of them
stalling and causing fvwm to lock up.  Is there a way of getting
XGrabServer to fail if the server is already grabbed? Maybe the
MyXGrabserver() for fvwm should broadcast a message when grabbing and
the modules MyXGrabServer()'s should not do the grab.

Cheers,
Tim.

---

From: Dan Espen <[email-masked]>
Date: Mon, 25 Jan 1999 09:07:34 -0500

> the modules MyXGrabServer()'s should not do the grab.

I don't see anything in the man pages about having XGrabServer fail if
its already grabbed.

I'm not sure  if  its necessary for  the  modules to know  about fvwm2
doing a grab.  It would seem to me like a case by case thing.

I don't think the  grabs have anything to   do with the  modules going
wild during recapture.  If they were doing a grab, they would just sit
there until the recapture was done, and then go wild.  I think its the
flood of  messages   into the module  that  causes  them to  go  wild.
Perhaps the messages shouldn't   be  sent during recapture,  (to   any
module), but that  sounds to me like something  we would want to think
about after 2.2.

The lockonsend thing is the key  part, fvwm2 tries to tell FvwmAnimate
that it iconified something, then waits for FvwmAnimate to say that it
got  the iconify  message.  FvwmAnimate won't  acknowledge the message
until it can grab the server and do the animation.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 25 Jan 1999 14:11:01 +0000

> event-loop code was lifted from. (I'll create a patch for FvwmIconMan

I've never seen this problem with FvwmIconMan and I run it all the
time.  The event loop might be the same but there must be some
difference elsewhere that prevents the problem in FvwmIconMan.  I
wouldn't just create a patch unless you figure out what the difference
is and FvwmIconMan has a real bug lurking.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 25 Jan 1999 15:53:01 +0000

> I don't see anything in the man pages about having XGrabServer fail if

Me neither. I think it just waits until it can get the grab. It's this
that I was worried about.

> there until the recapture was done, and then go wild.

This is exactly what happens.  The recapture completes (the window
frames get redrawn) and the FvwmWinList processes the flood of
messages.  It probably got the first message, decided to resize itself,
called XGrab, (which waits for fvwm to ungrab), does the XMoveResize,
then it can do the rest of the messages.

> until it can grab the server and do the animation.

I'm happy with your fix for this but I was a bit concerned that fvwm
might hang in recapture due to FvwmWinList not emptying its read pipe. I
haven't seen it hang so maybe it's not a problem.

The messages from fvwm to the modules happen while fvwm has the server
grabbed. Is it possible that a pausing FvwmWinlist might cause fvwm to
hang or can the message queuing stuff handle large message queues? If
the latter then I'm happy but when FvwmWinList was broken (the select
stuff) I had fvwm hangs. At least I'm fairly sure I did (focus didn't
change, couldn't pop up fvwm menus, pointer moved and cursor changed (so
it wasn't a server hang) and it only got going when I managed to get a
refresh event to FvwmWinList).

Cheers,
Tim.