This bug was reported by Douglas F. Elznic <delznic_at_acm.org> to the
redhat-list. See also the reply by Eze Ogwuma <typhoon_at_dircon.co.uk>.
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
hugh_at_mimosa.com
--
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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon Jan 26 1998 - 14:22:41 GMT