I use version 1.5.8 of dopewars, with mandrake linux 9.0
whenever a fight starts, the fight window freezes and i
can only kill it. the game exits then.
Logged In: YES
I can't reproduce this behaviour on a RedHat 8.0 box or
under Windows XP;
I need more details. Does this happen in single-player mode,
to a dopewars server, or both? If it happens when you
connect to a server,
does the server crash or not? When you say the "fight window
you mean the buttons don't work, the dopewars binary
sucking 100% CPU for no apparent reason, or it hangs
completely? (You can
test this by moving another window over the dopewars window
away again, to see if dopewars is able to redraw its
window.) Are you using
the default configuration file? Can you attach gdb to the
get a backtrace so I can see where it's getting stuck?
Logged In: YES
I have discovered that the crash happens when the sound
option is on. if I turn it off ( from the enable sound
button in the menu ) then the fights do not crash the game.
I have used the game in single player mode with default
the program hangs completely, it does not redraw the window.
i do not know how to attach gdb to it, if you tell me how to
do it, I will.
> I have discovered that the crash happens when the sound
> option is on.
Hmm. Again, this doesn't happen on my RedHat 8.0 test
system. Did you build the program from the source code, or
use the binary RPM? If the latter, then this may be due to
an incompatibility between RedHat and Mandrake - try
building from the source code, to see if that fixes it.
I take it "normal" sounds work without freezing the game?
(For example, a sound should be played whenever you move to
a new location.)
> i do not know how to attach gdb to it, if you tell me how to
> do it, I will.
From an xterm/console, do "ps auxw" or similar, and find out
the PID of the dopewars process. Then run "gdb
/usr/bin/dopewars 1234", changing the pathname of the
dopewars binary from /usr/bin, and the PID from 1234, as
appropriate. Then use the gdb command "bt" to get a stack
backtrace, and send me the output. (You may need to hit
Ctrl-C in the gdb window first to stop the dopewars process.)
indeed, the sound works in the game. i have attached the
file with the gdb output.
i wil ltry and get the sources now and recompile.
i didnt use the rpm's, I had used the tarball (v1.5.8)
sources. so there is no use to recompile it now.
The gdb backtrace shows that it's getting stuck in the ESD
code, and not in dopewars itself. This _might_ be an ESD
bug. Does the file "/usr/local/share/dopewars/colt.wav"
exist on your system, and can you play it? (I suggest you
change the configuration file via Game/Options so that it's
played when you jet to a new location, to see if it's that
WAV file that's causing ESD problems.)
Other things to try:
1. Run dopewars from gdb - i.e. "gdb /usr/bin/dopewars" and
then use the gdb "run" command to start the program. (If you
need to pass arguments to dopewars, append them to the gdb
run command.) Then use the same technique to get a stack
trace when the program crashes. That should give me more
details to work with. (Some of the function parameters look
a bit odd in the backtrace you sent me - but I can't see any
2. Edit the src/plugins/sound_esd.c file in the dopewars
source code, and change the second argument to the
esd_file_cache call (on line 85) from "" to "dopewars". That
might fix things.
i have modified the file sound_esd.c as you said and the
problem no longer occurs.
thanks for the help, I hope this is usefull for you too.
That's good news. I've made the same change now in CVS, so
this bug will be fixed in the next release. Thanks for
letting me know.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.