Subject: CVS olicha: * Added a list for the windows which are scheduled for destroy

From: FVWM CVS <[email-masked]>
Date: Tue, 20 May 2003 04:39:22 -0500

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	olicha	03/05/20 04:39:22

Modified files:
	.              : ChangeLog 
	fvwm           : add_window.c focus.c screen.h update.c 
	libs           : FGettext.c Flocale.c Makefile.am 
Added files:
	libs           : flist.c flist.h 

Log message:
* Added a list for the windows which are scheduled for destroy
* Always remove a fw from the fw list when destroy_window
* Added a flist structure and some basic function for handling such structure
* Use the new flist struct and functions interface in FGettext
* Allowed empty xft font name
* #if 0 some debug code in focus.c

--
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: Olivier Chapuis <[email-masked]>
Date: Thu, 22 May 2003 19:10:51 +0200

> * Always remove a fw from the fw list when destroy_window

There is something broken in this commit. Please, Mikhael do
not release 2.5.7 before I (or Dominik) fix it.

Regards, Olivier

---

From: [email-masked]
Date: Sun, 25 May 2003 01:20:55 +0200

> not release 2.5.7 before I (or Dominik) fix it.

What exactly is the problem?

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: Olivier Chapuis <[email-masked]>
Date: Mon, 26 May 2003 12:25:34 +0200

> What exactly is the problem?

I would like to have an answer. I get a core dump (stacking ring
corruption?)  or fvwm windows which have lost its client window when I
"run" purify.fvwm2rc.  Here the story.

* Before the 2003-05-18, one logic in destroy_window was to
    - remove the window from the fvwm window list
    - test if the window should be scheduled for destroy
       if yes, return after some job
       if no, really destroy/free the fvwm window
The problem was: when it is the time to really destroy/free the fvwm
windows which are scheduled for destroy (in update.c) as the window
has been removed from the fvwm window list fvwm do not found these
fvwm windows!
  
* On the 2003-05-18 I commit a fix by inverting the logic above:
    - test if the window should be scheduled for destroy
         if yes, return after some job
    - if no remove the window from the fvwm window list
    - really destroy/free the fvwm window
I thought that was not so bad as the scheduled_for_destroy flags is
maybe here to forbid certain operations on the fvwm windows in the
fvwm window list which are scheduled for destroy.  Indeed, I've _no_
problems with this logic (no core dump no fvwm windows which have lost
is client). But, you suggest that this logic is bad (and yes some
"operations" are performed on some fvwm windows which are scheduled
for destroy).

* So, I restored the previous logic (2003-05-20) and add a simple list
of the windows which are scheduled for destroy. This list is used in
update.c to really destroy/free the fvwm window.

I do not know what is the problem ... maybe under certain situation
the window which are scheduled for destroy are put back in the fvwm
window list in a strange way, that I do no understand.

Here the core dump I get when I "run" purify.fvwm2rc. It is not 100%
reproducible (but always happen at the same place during the Iconify
test). I reproduce it more easily if I proceed as follows (need to cvs
update first for my last purify.fvwm2rc commit):

  - install "purify"
  - run fvwm without config
  - Open a FvwmConsole and type:
     Read path_to_fvwm_cvs_tree/tests/purify/purify.fvwm2rc
     PurifyInit
  - pop-up the purify menu and select
      "Some Setup" -> "Bloc on Pick after each test"
  - Then, "run all test". You should click and click again to progress
    in the tests 

When I've no core dump I've a "window7" which has lost its
client. The same core dump occur with fvwm version prior to
the 2003-05-18.

#0  0x0808d968 in __raise_or_lower_window (t=0x0, mode=8389217,
    allow_recursion=1, is_new_window=135186360) at stack.c:823
823                                     XRaiseWindow (dpy, FW_W_FRAME(t2));
(gdb) where
#0  0x0808d968 in __raise_or_lower_window (t=0x0, mode=8389217,
    allow_recursion=1, is_new_window=135186360) at stack.c:823
#1  0x0808e1eb in RaiseWindow (t=0x81ae9e0) at stack.c:1417
#2  0x080813b6 in DeIconify (fw=0x81ae9e0) at icons.c:2405
#3  0x08081b19 in CMD_Iconify (cond_rc=0xbfffeb04, exc=0x1,
    action=0x81dba30 " 0 \"True\" üpikü") at icons.c:2671
#4  0x08099b22 in __execute_function (cond_rc=0xbfffeb04, exc=0x81ebe08,
    action=0x81d0598 "E", exec_flags=0 '\0', args=0x81dba30) at functions.c:636
#5  0x0809a7ef in execute_function (cond_rc=0xbfffeb04, exc=0x81ebe08,
    action=0x81de636 " Iconify  0 \"True\" üpikü", exec_flags=0 '\0')
    at functions.c:1228
#6  0x0809d1e3 in circulate_cmd (cond_rc=0xbfffeb04, exc=0x81ebe08,
    action=0x81de62d "(window2) Iconify  0 \"True\" üpikü", new_context=1,
    circ_dir=1, do_use_found=1, do_exec_on_match=1) at conditional.c:198
#7  0x0809e1ef in CMD_Next (cond_rc=0xbfffeb04, exc=0x81b4bf8,
    action=0x81de62d "(window2) Iconify  0 \"True\" üpikü")
    at conditional.c:876
#8  0x08099b22 in __execute_function (cond_rc=0xbfffeb04, exc=0x81ef898,
    action=0x81b4bf8 "E", exec_flags=128 '\200', args=0x81de62d)
    at functions.c:636
#9  0x0809a037 in __run_complex_function_items (cond_func_rc=0xbfffeb04,
    cond=105 'i', func=0x1, exc=0x81ef898, args=0xbfffeb90) at functions.c:822
#10 0x0809a28f in execute_complex_function (cond_rc=0xbfffed24, exc=0x81eb248,
    action=0x81ef898 "E", desperate=0x5) at functions.c:992
#11 0x08099bcf in __execute_function (cond_rc=0xbfffed24, exc=0x817a750,
    action=0x81eb248 "E", exec_flags=128 '\200', args=0x81db9a1)
    at functions.c:655
#12 0x0809a037 in __run_complex_function_items (cond_func_rc=0xbfffed24,
    cond=105 'i', func=0x1, exc=0x817a750, args=0xbfffedb0) at functions.c:822
#13 0x0809a28f in execute_complex_function (cond_rc=0xbfffee4c, exc=0x817a6c8,
    action=0x817a750 "E", desperate=0x5) at functions.c:992
#14 0x08099bcf in __execute_function (cond_rc=0xbfffee4c, exc=0x817a640,
    action=0x817a6c8 "E", exec_flags=64 '@', args=0x811f719) at functions.c:655
#15 0x0809a7ef in execute_function (cond_rc=0x0, exc=0x817a640,
    action=0x811f710 "function TestFunc", exec_flags=64 '@')
    at functions.c:1228
#16 0x0804e2e0 in __menu_execute_function (pexc=0xbffff0b8,
    action=0x811f710 "function TestFunc") at menus.c:228
#17 0x080566f7 in do_menu (pmp=0x0, pmret=0xbffff0c0) at menus.c:6439
#18 0x080ad7f8 in menu_func (cond_rc=0xbffff1bc, exc=0x8177ca0, action=0x0,
    fStaysUp=1) at menucmd.c:116
#19 0x080ad908 in CMD_Menu (cond_rc=0xbffff1bc, exc=0x8177ca0,
    action=0x81201b5 "TestMenu") at menucmd.c:145
#20 0x08099b22 in __execute_function (cond_rc=0xbffff1bc, exc=0x8177ea8,
    action=0x811fac0 "Hû\021\bHþ\021\bh", exec_flags=0 '\0', args=0xbffff0d0)
    at functions.c:636
#21 0x0809a7ef in execute_function (cond_rc=0x0, exc=0x8177ea8,
    action=0x8177dd8 "Menu TestMenu", exec_flags=0 '\0') at functions.c:1228
#22 0x08060676 in __handle_bpress_on_root (exc=0x8177ea8) at events.c:607
#23 0x08060859 in HandleButtonPress (ea=0xbffff2e4) at events.c:721
#24 0x08063aa8 in dispatch_event (e=0xbffff330) at events.c:3261

---

From: [email-masked]
Date: Tue, 27 May 2003 02:34:55 +0200

On Mon, May 26, 2003 at 12:25:34PM +0200, Olivier Chapuis wrote:
[snip]
> "operations" are performed on some fvwm windows which are scheduled

Some functions may be executed on it while a complex function is
still running.  For example:

  AddToFunc foo
  + I Destroy
  + I Echo $w $n

  Next (FvwmConsole) foo

This first destroys the window and then prints the window's name
and id.  However, the window must not be found in the window list
anymore so it is not considered in most of the code.

> client.

> The same core dump occur with fvwm version prior to
> the 2003-05-18.

I never saw this core dump, but there were a number of bugs that
were triggered by the Style2-Func in the script.  It boiled down
to something like

  AddToFunc Style2-Func
  + I Exec xterm -geometry 10x5 -T window1 -n window1 -e sleep 1000
  + I Wait window1
  + I All (window*) Close
  + I Exec xterm -geometry 10x5 -T window2 -n window2 -e sleep 1000
  + I Wait window2
  + I All (window*) Close
  + I Exec xterm -geometry 10x5 -T window3 -n window3 -e sleep 1000
  + I Wait window3
  + I All (window*) Close
  + I Exec xterm -geometry 10x5 -T window4 -n window4 -e sleep 1000
  + I Wait window4
  + I All (window*) Close
  + I Exec xterm -geometry 10x5 -T window5 -n window5 -e sleep 1000
  + I Wait window5
  + I All (window*) Close

 1) The next and prev members of the window still pointed to the
    window list (fixed by you in 2.5.7 and by me in 2.4.x).
 2) The code in focus.c ignored the fact that the prev member of
    the window may not have contained anything useful (fixed in
    2.4.x and 2.5.7).
 3) If destroy_window() was called multiple times for a single
    window, it did some of the work twice, e.g. unmapping the icon
    and broadcasting a message (fixed in 2.4.x and 2.5.7).
 4) Once a window was destroyed, X sometimes reuses the same
    window id.  If the timing was right, the code in add_window.c
    called XDeleteContext on that window id and deleted the
    context of the new window assuming it was still swallowed in
    the old frame.  Later, the window got destroyed but fvwm
    ignored the event because it did not find an associated frame.
    (fixed in 2.4.x and 2.5.7).

These patches may or may not have fixed the core dump you got.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 27 May 2003 07:33:33 +0200

> These patches may or may not have fixed the core dump you got.

I cannot reproduce the core dump anymore. I do not have window7 windows
without clients at the end of the Test too.

Great, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 27 May 2003 10:56:35 +0200

> without clients at the end of the Test too.

I had them when I ran the Style2-Func from the purify script, but
with the fixes above the problem is gone. (Mainly problem 4).

Bye

Dominik ^_^  ^_^