On Tue, May 27, 2003 at 07:33:33AM +0200, Olivier Chapuis wrote: > On Tue, May 27, 2003 at 02:34:55AM +0200, [EMAIL PROTECTED] wrote: > > On Mon, May 26, 2003 at 12:25:34PM +0200, Olivier Chapuis wrote: > > [snip] > > > * 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. > > > > I cannot reproduce the core dump anymore. I do not have window7 windows > 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 ^_^ ^_^ -- 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]
