On Sun, May 25, 2003 at 01:20:55AM +0200, [EMAIL PROTECTED] wrote:
> On Thu, May 22, 2003 at 07:10:51PM +0200, Olivier Chapuis wrote:
> > On Tue, May 20, 2003 at 04:39:22AM -0500, FVWM CVS wrote:
> > > 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
> >
> > There is something broken in this commit. Please, Mikhael do
> > not release 2.5.7 before I (or Dominik) fix it.
>
> 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
--
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]
