Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!usenet.ins.cwru.edu!kira.cc.uakron.edu!ns.mcs.kent.edu!borsburn
From: borsburn@mcs.kent.edu (Bret Orsburn)
Newsgroups: comp.os.386bsd.bugs
Subject: Bugs in Xboing 1.8
Date: 12 Aug 1994 16:45:41 GMT
Organization: Kent State University
Lines: 88
Message-ID: <32g8vl$6i6@ns.mcs.kent.edu>
NNTP-Posting-Host: condor.mcs.kent.edu
I've been sitting on this bug report for a few weeks. I'm not very happy
with it because I didn't really get to the root cause of any of the bugs.
I've finally decided to post it because it includes enough work-arounds to
let people play a generally well-produced game.
I hope people with the appropriate expertise can use this info to locate
the real problems.
----------------------
I've found three significant bugs in xboing 1.8 as it appears on the 2nd issue
of the BSDisc (corresponding to the package and port on freebsd.cdrom.com on
or around the BSDisc closing date). I've chased the first two bugs as far as
the kernel and the 3rd into an apparent problem with the game logic. I've found
work-arounds for all of the problems, but I've hit the point of diminishing
returns on the learning curve, so I'll leave any real fixes to people who
already know the territory.
I'm running FreeBSD 1.1.
1) When compiled with lockf file locking (the default), the program frequently
hangs with ps indicating the process is waiting on WCHAN lockf. Since xboing
runs with a pointer grab by default, this mode of failure is very disruptive.
The problem goes away if xboing is compiled without locking. (I have not tried
flock locking.)
2) The second problem arises when audio is enabled and one attempts to exit
the program (e.g. by typing 'Q' 'Y' from the demo screen). The current xboing
child process exits immediately, but if there is an active audio parent
process, the audio parent process often (unaccountably) gets stuck in a write
to the audio device. (FWIW, I'm using a Soundblaster Pro)
The good news in this case is that the audio process resumes (returns from the
write) exactly one minute later!? The bad news is that the X Server connection
doesn't close until the the audio process wakes up, so the game display remains
on the screen and the pointer grab remains in effect for a minute after exit.
This problem can be worked around by adding this to FreeAudioSystem:
if (parentpid) {
kill(parentpid,9);
parentpid = 0;
}
3) The last problem I've looked into seems to be in the game logic: from time
to time, a level fails to end when the last block is gone. This is essentially
a fatal error, because there is no way to exit the level -- eventually, the
player runs out of balls and the game ends.
I poked around in the program a little and found that sometimes
blocksExploding > 0
when there are no active blocks. It seems that an invariant is being violated
somewhere.
This may be timing-related: it seems to happen more frequently at speed 2.
I added a work-around to ExplodeBlocksPending that sets blocksExploding = 0
when the outer loop finds no active blocks. I haven't tried to master the
program logic in sufficient detail to find the place where the invariant is
being violated.
---
A general observation: the audio architecture of xboing 1.8 seems pretty
radical. There ought to be a way to make noises without forking and killing
for every sound. (There is supposed to be a netaudio version of xboing --
that seems like a more reasonable approach.)
Meanwhile, I recommend xboing 1.8 (with audio enabled) to the FreeBSD
development team as a kernel torture test: they probably never anticipated
this rate of forking and killing!
---
Note to folks reading this on freebsd-bugs: I don't know if it's appropriate
to report package bugs to the freebsd-bugs list. I wanted to send it to a
freebsd list because there seem to be kernel/driver problems involved. Let
me know if this should have gone to a different list.
---
Bret Orsburn
borsburn@mcs.kent.edu