Subject: FVWM: FvwmButtons burns CPU [was: FVWM Buttons X3 at 28.5 % CPU]

From: [email-masked] ("D. Hugh Redelmeier")
Date: Mon, 26 Jan 1998 15:19:44 -0500

This bug was reported by Douglas F. Elznic <[email-masked]> to the
redhat-list.  See also the reply by Eze Ogwuma <[email-masked]>.
My report has more details.

[I'm running Red Hat 5.0, but I had a previously unexplained
phenomenon under RH4.2 for which this could account.  I'm running
fvwm2 (2.0.46), the default window manager.  I don't know how to tell
the version of FvwmButtons.  I have done little customization except
that I am running a newer X server (from SuSE, blessed by XFree86.org)
to support my video card.  I don't think that is relevant.]

When I shut down my X server using control-alt-backspace, FvwmButtons
does not terminate.  Worse, it burns all the CPU time that it can get.
When I first noticed this, I had a half dozen of the things splitting
the CPU between them.

Observations:
- C-A-BS shutdown leaves FvwmButtons burning cpu
- loging out doesn't stop it
- using strace on the FvwmButtons process after it has gotten into this
  state shows that *no* system calls are being made
- using strace on the FvwmButtons process from before C-A-BS results
  in FvwmButtons exiting properly!!!
- shutting down from the Start menu correctly terminates FvwmButtons

The fact that strace changes the result suggests that there is some
race condition involved.

When I examine the process using GDB, it seems to be endlessly
repeating the following sequence of instructions:

 0x40054ba4 <_XFlushInt+44>:	movl   0x4c4(%edi),%eax
 0x40054baa <_XFlushInt+50>:	testl  %eax,%eax
 0x40054bac <_XFlushInt+52>:    je     0x40054bbb <_XFlushInt+67>

 0x40054bbb <_XFlushInt+67>:	testb  $0x40,0x94(%edi)
 0x40054bc2 <_XFlushInt+74>:    jne    0x40054ba4 <_XFlushInt+44>

Every time it looks at the 32-bit quantity at 0x4c4(%edi), it seems to
find it zero.  Every time it checks the 0x40 bit in the byte at
0x94(%edi), it finds it on.  Nothing in this loop will change these
memory locations; I suspect that there is no longer an asynchronous
event to change them.

A "where" GDB command yields:
#0  0x40054bac in _XFlushInt ()
#1  0x40054b72 in _XFlush ()
#2  0x4005205e in XSync ()
#3  0x804989f in _start ()
#4  0xbfffefb4 in ?? ()
#5  0x40054b72 in _XFlush ()
#6  0x4005205e in XSync ()
#7  0x804989f in _start ()
#8  0xbffff13c in ?? ()
#9  0x4006ddbd in _X11TransWrite ()
#10 0x40054c34 in _XFlushInt ()
#11 0x40054b72 in _XFlush ()
#12 0x40054d08 in _XEventsQueued ()
#13 0x4004a5d0 in XPending ()
#14 0x804b725 in _start ()
#15 0x804a31f in _start ()
#16 0x804a2fb in _start ()

- Frame 0 is an invocation of _XFlushInt, apparently an internal-to-xlib
  function.
- It was called by _XFlush() which was called by XSync (XSync is a
  public xlib function).
- I don't know what Frame's 8 and 9 are about; perhaps signal handling
  is going on (that might mess up a stack frame)
- OOPS: _XFlushInt() and _XFlush() appear in 10 and 11.  Are they
  really meant to be re-entrant?

My *guess* is that something is being done in a signal handler that
isn't safe.  Note that almost nothing is safe in a signal handler
(according to the ANSI/ISO standard for C).

Hugh Redelmeier
[email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 26 Jan 1998 15:52:22 -0500

>>>>> "Hugh" == "D Hugh Redelmeier" <[email-masked]> writes:

Hugh> This bug was reported by Douglas F. Elznic <[email-masked]> to the
Hugh> redhat-list.  See also the reply by Eze Ogwuma <[email-masked]>.
Hugh> My report has more details.
....
Hugh> My *guess* is that something is being done in a signal handler that
Hugh> isn't safe.  Note that almost nothing is safe in a signal handler
Hugh> (according to the ANSI/ISO standard for C).

Yes, there are a number of these signal handler problems in fvwm.  A
patch has been submitted (from Grant McDorman) and will appear in the
next version (2.0.47).  Search the mailing list archives if you want
it sooner.

Chuck

--
*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Fire Dragon <[email-masked]>
Date: Fri, 30 Jan 1998 12:02:43 -0600 (CST)

> When I first noticed this, I had a half dozen of the things splitting

looks the exact same thing I have fun with here at since redhat betas of
4.8, 4.8.1, 4.9 and 4.9.1 (possibly 4.2 but I don't remember it)

The funny thing is even Ctrl-Alt-BkSp from XDM will do the same thing
which i would have thought it would keep it working and kill it... gues
not...

I would have thought that the FvwmButtons is a child of the X process but
from my looking into the startx and all of those scripts it appears to be
part of xinitrc...

ttylz

--
Fire Dragon			|	RedHat 5.0 & Cyrix 6x86 P120+
[email-masked]	|	Linux Kernel 2.1.82 and counting!
http://nosferatu.world-net.net	|	What more could you ask for?
ftp://nosferatu.world-net.net	|	Linux: For IQs higher than 95!

Pray to God, but keep rowing to shore.
		-- Russian Proverb