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. Great, Olivier -- 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]
