Subject: fvwm fails to capture windows during startup

From: Dan Espen <[email-masked]>
Date: Sun, 28 Nov 1999 07:40:22 -0500

I'm starting XEmacs like this from my .xinitrc:

(sleep 20;xemacs -iconic&)&

There are times  when fvwm fails to put  any kind of frame  around the
window.  (It normally has a frame.)  A restart cures the problem.

The delay  was put  in there  because  XEmacs was core  dumping during
startup.  I suspected it was due to  fvwm putting frames on the window
as XEmacs was starting.  Now, my  startups (from home) are taking much
longer than  20  seconds.  I'm guessing  there is  some period of time
during startup where a window being created won't be noticed by fvwm.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214             E-mail: [email-masked]
Piscataway, NJ 08854                       Phone: (732) 699-5570
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 29 Nov 1999 14:22:22 +0100

> during startup where a window being created won't be noticed by fvwm.

Dan, there are several places in the AddWindow function where
grabbing the window may fail.  Can you find out if AddWindow
is called at all and if it is where it returns?  My guess is
that one of the XGetGeometry calls at the start of the function
fails.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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: Dan Espen <[email-masked]>
Date: Mon, 29 Nov 1999 19:55:10 -0500

> that one of the XGetGeometry calls at the start of the function

With the debugging added,  and without XSynchronize,  so far I've been
unable to reproduce the problem.

I just wanted to comment about that XSynchronize  and something else I
noticed.  At work   I didn't notice   anything unusual, but  at home I
thought I was having some kind of problem with my cable modem.

Normally menus just  flash on to  the screen.  With XSynchronize, they
drew themselves one line at a time, about 2 seconds  per line.  What I
found odd is that I can plainly see a whole  bunch of data transferred
back and forth after the menu is completely displayed.

Oh,  I just checked again,  whats going on is, as  long as the pointer
stays on the title, there's  constant network traffic back and  forth.
It can be a title anywhere in the menu.

(This is fvwm2 running on a Sun, Exceed running on  the other end of a
cable modem.)

I'm still using current CVS.

Whether this is a problem or not, I don't know.  It sort of looks like
one  to me.  I know  lots of users are running  fvwm across a network.
Perhaps not one this slow.

Before sending this, I thought I'd take another stab at it.
Here are some stack dumps while this is happening:

fork> sleep 10 ;/usr/proc/bin/pstack 5718
5718:   /opt/public/src/fvwm/2.3.11/fvwm2
 ef437438 poll     (efffa3c8, 1, ffffffff)
 ef44cc74 select   (efffa3d0, ef4a60b4, ef4a60b4, ef4a60b8, ef4a60b8, 4) + 280
 ef649488 _XWaitForReadable (a7b20, 1, 3, 8, ef4a3138, ef488284) + e0
 ef60f704 _XRead   (20, efffc5d0, 20, 20, ffffffff, a7b20) + e4
 ef6119cc _XReply  (a7b20, 3b60, 0, 3b60, 20, a7b20) + 150
 ef621db8 XQueryPointer (a7b20, 2a, a6fa4, efffc66c, efffc67c, efffc678) + 80
 0001cc18 find_entry (0, efffc818, fffdfc00, 0, efffc7c4, efffc7b8) + 90
 00020ba0 MenuInteraction (efffc9c8, efffc9b8, efffc8b8) + 19e4
 0001db38 do_menu  (efffc9c8, efffc9b8, fbfffc00, effffc00, 0, efffc9f8) + 4c8
 0002b1ac menu_func (a5ad4, 2a, 0, 8, 101485, efffcbdc) + 334
 0002b284 staysup_func (a5ad4, 2a, 0, 8, 101485, efffcbdc) + 3c
 00068dd4 ExecuteFunction (d1ce0, 0, a5ad4, 8, ffffffff, 1) + 4b0
 0003cbb0 HandleButtonPress (a6010, a6000, 10, a5ff8, ef67c2f4, ff4a8) + 7b4
 00039434 DispatchEvent (0, a5ad4, a5800, efffbcf0, f, efffbcd0) + 100
 000394e8 HandleEvents (0, a4800, 234, a6410, 64, 13) + 80
 00040700 main     (1, efffd1d4, efffd1dc, a5ab0, 0, 0) + 1eb8
 0001c154 _start   (0, 0, 0, 0, 0, 0) + 5c

fork> sleep 10 ;/usr/proc/bin/pstack 5718
5718:   /opt/public/src/fvwm/2.3.11/fvwm2
 ef438c7c sigsuspend (efffc608)
 ef438c7c _libc_sigsuspend (efffc608, efffc688, 0, ef4a5a2c, ef4a3138) + 4
 ef454168 usleep   (2710, f4240, ef4a3138, 0, ffffffff, 2000) + 1b8
 0001f550 MenuInteraction (efffc9c8, efffc9b8, efffc8b8, a4a1c, a4800, f2) + 394
 0001db38 do_menu  (efffc9c8, efffc9b8, fbfffc00, effffc00, 0, efffc9f8) + 4c8
 0002b1ac menu_func (a5ad4, 2a, 0, 8, 101485, efffcbdc) + 334
 0002b284 staysup_func (a5ad4, 2a, 0, 8, 101485, efffcbdc) + 3c
 00068dd4 ExecuteFunction (d1ce0, 0, a5ad4, 8, ffffffff, 1) + 4b0
 0003cbb0 HandleButtonPress (a6010, a6000, 10, a5ff8, ef67c2f4, ff4a8) + 7b4
 00039434 DispatchEvent (0, a5ad4, a5800, efffbcf0, f, efffbcd0) + 100
 000394e8 HandleEvents (0, a4800, 234, a6410, 64, 13) + 80
 00040700 main     (1, efffd1d4, efffd1dc, a5ab0, 0, 0) + 1eb8
 0001c154 _start   (0, 0, 0, 0, 0, 0) + 5c

I thought I'd built this with -g, I'm not sure if "pstack" will give me
line numbers anyway.

Anyway, I've got to eat sometime...

Later,