On Mon, May 26, 2003 at 12:25:34PM +0200, Olivier Chapuis wrote:
[snip]
> * 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).
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.
> * 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.
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 ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
