I've fixed the problem by running vavoom with the no sound option. This is related to the timidity file and the line mentioned has the following comment and code. It looks like this may be getting a zero when it should not. My system is an AMD quad core 64 bit Phenom. The kernel is the generic one.

#ifdef PRECALC_LOOPS int32 i, j; if (incr<0) incr = -incr; /* In case we're coming out of a bidir loop */ /* Precalc how many times we should go through the loop. NOTE: Assumes that incr > 0 and that ofs <= le */ i = (le - ofs) / incr + 1; if (i > count) { i = count; count = 0; } else count -= i; for(j = 0; j < i; j++) { RESAMPLATION; ofs += incr; } if (ofs >= le) { FINALINTERP; vp->status=VOICE_FREE; ctl->note(v); *countptr-=count+1; }

vavoom-1.30-1.fc11.x86_64, vavoom-debuginfo-1.30-1.fc11.x86_64 md5sum abb033caf81e26f12a2103e1fa25453f hexen.wad This is annoyingly random. I can't consistently reproduce it. I will get what GDB needs and run vavoom in a window rather than fullscreen and hope that keeps vavoom from locking up the x server. I'd like to get a backtrace. The error shown in the debug.txt file did not hard lock the x server. Relevant part:

Uninitialised: Doing Z_Shutdown STACK TRACE: stack 0 0x6485d4 frame 0 0x7fff2d6a74f0 ERROR: Floating Point Exception

May be related: Earlier I managed to catch a failure with GDB. It's not complete as I don't have my system fully set up to do debugging and this one hard locked xorg. I think GDB allowed me to access the virtual terminals and kill vavoom. Normally it would hard lock the x server and ctrl-alt-bksp is needed to kill it.

Program received signal SIGFPE, Arithmetic exception. 0x0000000000676fe6 in rs_plain (countptr=<value optimized out>, v=<value optimized out>) at /usr/src/debug/vavoom-1.30/source/timidity/resample.cpp:91 91 i = (le - ofs) / incr + 1;