Subject: fvwm cvs and gkrellm race condition

From: "S. Anderson" <[email-masked]>
Date: Mon, 12 Aug 2002 22:07:14 -0600

I may have found a bug, to reproduce...

1. I start fvwm without a rc file, 
2. then execute gkrellm from a xterm,
3. then I click on the gkrellm window(not the fvwm decorations) and 
   wiggle it around.
4. repeat step 3 a few times. 

fvwm, gkrellm and X start fighting for cpu use. Memory used starts 
filling up really fast. And I cant do anything execpt ctrl-alt-bkspce.

GKrellM 1.2.13
gtk 1.2.10
Xfree86 4.2.0
Linux 2.4.19 i686 AuthenticAMD
sa@f ~ % fvwm-config -i
Package: fvwm
Version: 2.5.3

Instalation options:
        prefix: /home/sa/local
        exec-prefix: /home/sa/local
        bindir: /home/sa/local/bin
        datadir: /home/sa/local/share
        libexecdir: /home/sa/local/libexec
        sysconfdir: /home/sa/local/etc
        mandir: /home/sa/local/man

Compiled-in paths:
        Module directory: /home/sa/local/libexec/fvwm/2.5.3
        Data directory: /home/sa/local/share/fvwm
        Perl lib directory: /home/sa/local/share/fvwm/perllib
        Default ImagePath:
/usr/include/X11/bitmaps:/usr/include/X11/pixmaps
        Default UserDir: $HOME/.fvwm

Support for features:
        bidi (bi-directionality): no
        ewmh (Extended Window Manager Hints): yes
        gnome-hints (window manager hints): yes
        gtk (required for FvwmGtk): yes
        gdk-imlib (in FvwmGtk): yes
        gnome-libs (in FvwmGtk): yes
        perllib (Perl library installed): yes
        png: yes
        readline: yes
        rplay: no
        shape (shaped windows): yes
        sm (session management): yes
        stroke (mouse gestures): yes
        xinerama (multi-head): yes
        xft (FreeType anti-alias font): yes
        xpm: yes
        xrender (XFree86 Xrender extention): yes

let me know if you need any other info,
cya,
sa

--
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: Tue, 13 Aug 2002 11:40:28 +0200

> Linux 2.4.19 i686 AuthenticAMD

With the same versions, it doesn't happen here.  Is the fvwm-2.5.3
latest CVS?

> let me know if you need any other info,

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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: "S. Anderson" <[email-masked]>
Date: Tue, 13 Aug 2002 14:43:32 -0600

> With the same versions, it doesn't happen here.  Is the fvwm-2.5.3

yes updated on aug 12th. I downloaded fvwm-snap-20020810 and It doesnt
have this problem. I just figured out, If I
#undef EXPERIMENTAL_ANTI_RACE_CONDITION_CODE
in fvwm/events.c at line 1081 I dont have this problem anymore.
is the experimental anti race condition code important, should I not
disable it?
also I forg÷t to mention I am using gcc 3.1.1, and It is not only
gkrellm, but xmms and xine too.

cya,
sa

---

From: "S. Anderson" <[email-masked]>
Date: Wed, 14 Aug 2002 01:17:54 -0600

> gkrellm, but xmms and xine too.

ok, some more info...
this is the output that fvwm spits out. I get this race condition 
right before it prints 'cn_count = 22507546', I let fvwm run until
my system ran out of resources.
cya,
sa

sa@f ~ % fvwm
cn_count = 0
cre: 1210(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 0(0) 0(0) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 1202(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 1184(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 1162(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 1136(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 457502
cre: 1100(1) 612(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 256(1) 516(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 266(1) 514(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 284(1) 512(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 310(1) 504(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 346(1) 500(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 390(1) 496(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 438(1) 492(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 496(1) 488(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 552(1) 488(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 491(1) 606(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 0
cre: 841(1) 490(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
cn_count = 22507546
cre: 578(1) 229(2) 67(0)x345(0) fw 0x00600147 w 0x00e00006 ew 0x00e00006  'gkrellm'
zsh: killed     fvwm
sa@f (137)~ %

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Aug 2002 11:22:13 +0200

> > is the experimental anti race condition code important, should I not

It's experimental.  And it's meant to reduce the chance of such
ConfigurRequest/ConfigureNotify races happening, but it looks like
my latest addition has a bug.

> > also I forg?t to mention I am using gcc 3.1.1, and It is not only

> sa@f ~ % fvwm
 ...
> cn_count = 457502
...
> cn_count = 22507546

Uh, oh!  22.5 million ConfigureNotify events that are going to be
sent to the application?  No wonder it hogs CPU.  Maybe I'm using
an uninitialised variable.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Aug 2002 11:34:31 +0200

> an uninitialised variable.

Fixed.

Bye

Dominik ^_^  ^_^