Subject: Strange behavior in Close_Delete_Destroy test

From: Dan Espen <[email-masked]>
Date: Sun, 10 Dec 2000 19:13:00 -0500

I've upgraded the CloseDeleteDestroy test so that it kills the 6
windows created in the CreateWindows test and then recreates them.

You can run this test by first reading the tests/purify/purify.fvwm2rc
file and then running the functions:

CreateWindows-Func
Close_Delete_Destroy-Func

You can use then button 1 menu or type in the commands in
FvwmCommand/Talk.

For me, when it starts running Close_Delete_Destroy, it looks like fvwm
detaches the frame from the first window and never gets any farther.

I found that running EscapeFunc (Ctrl-Alt-Escape)
helps it along, but test never seems
to complete.

Without using EscapeFunc I get messages about CreateWindows-Func
and makewindows func being in use, so I guess its getting hung up
in the waits in CreateWindows-Func, but I don't see why.

-- 
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://www.fvwm.org/>.
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: Dominik Vogt <[email-masked]>
Date: Sun, 17 Dec 2000 20:12:03 +0100

> in the waits in CreateWindows-Func, but I don't see why.

Fixed.

I learned something new about X.  The problem was this:  Since a
patch I made a few days ago, windows are not immediately destroyed
within complex functions but after all functions completed.  The
close function asks teh client to kill the window, and xterm
complies and thus generates a DestroyNotify.  But the window
structure is not cdestroyed yet.  Explicitly, the FvwmContext is
not deleted from the client window.  Now, a new window is created
and another 'wait' in the same function waits for the new window.
Unfortunately, X uses the same memory that was associated to the
already destroey other window and the application generates a
MapRequest.  Fvwm uses XFindContext() to find out the associated
FvwmWindow structure.  And, know what - X replies that the *new*
window is associated with the *old* FvwmWindow structure which
messes up everything :-P  In other words: a context associated
with a resource is not deleted when the resource is destroyed.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Thu, 21 Dec 2000 23:00:09 -0500

> with a resource is not deleted when the resource is destroyed.

Try running the CreateWindows test followed by the
CloseDeleteDestroy test.

It seems different, but still not right.
None of the original 6 windows go away.

The original 6 windows won't refresh when obscured or take focus.

Close the new windows with control-C.
Now moving one of the original windows kills it.

Sorry if the explanation isn't clear, try it.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 22 Dec 2000 23:18:05 +0100

> The original 6 windows won't refresh when obscured or take focus.

What you see are the naked frames when the client application has
already died.  Of course it can't refresh or take focus then :-)

> Now moving one of the original windows kills it.

Since the window destruction patches are an important feature
here is a bit of background info on the problem:

With the changes I made, windows are no longer destroyed
immediately if a complex function is running.  This change was
necessary to keep the window list consistent inside complex
functions.  Instead, a flag is set in the window structure to
indicate that the window must be destroyed.  Two global flags are
set as well, one to indicate that at least one window must be
killed after the function completes and the general flag that
any window updates have to be applied.  The flush_window_updates()
function was called while still inside a complex function, and
thus the code did not destroy any windows, but deleted the
Scr.flags.do_need_window_update flag - and thus the window
destruction code was never really executed.  As a fix, I have
separated the window update code from the window destruction
code.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Fri, 22 Dec 2000 20:09:02 -0500

I put this is the new Iconify test:

AddTest "Test Iconify" Iconify-Func
AddToFunc Iconify-Func
 + I Next [window6] Iconify toggle
 + I Next [window6] Iconify toggle
 + I Next [window6] Iconify toggle
 + I Next [window6] Iconify toggle

I start with window6 open.
It looks like it will do the 3 toggles, and thats it.
The window ends up in an iconified state.
Adding more window6 toggles, toggling other windows, and
piperead sleep delays don't help.

It seems like there is a limit to how often you can iconify a window
during a function.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 23 Dec 2000 12:57:27 +0100

> It seems like there is a limit to how often you can iconify a window

That is no bug.  Iconifying is not synchronous to function
execution.  An 'iconify' is not simply an atomic operation but
requires a proper response from the X server (mapping/unmapping
windows).  There is a short delay between the 'iconify' command
and the operation being completed.  Further 'iconify' calls do not
necessarily show the expected effect.  In the past, there was a
race condition between command execution and event handling.  The
internal state of a window was sometimes corrupted so that the
frame was mapped, but the client window was 'iconified', i.e.
unmapped.  The new code keeps track of this and throws away
iconify requests under certain circumstances.  This is what you
see.

The reason why additional delays do not help is that events are
not handled during this delay.  You could create windows and wait
for them with 'wait' to enforce event handling.

Bye

Dominik ^_^  ^_^