I've downloaded and installed the Gish demo and encountered a crash deep in the OpenAL code when attempting to select either play. options or by letting the intro track complete its play through. It only occurs if music is enabled and I was able to play the game by starting the demo with
./gish -nosound
disabling music and then restarting the demo with
./gish -sound
I'm thinking that either changing the music tune or restarting the current one triggers the bug.
The following is the output from the ./gish executable:
... (many other hash.c:395 lines)
[hash.c:395] failed read
[hash.c:395] failed read
[hash.c:395] failed read
jmalloc silently ignoring 0 alloc from al_queue.c 442
jmalloc silently ignoring 0 alloc from al_queue.c 443
gish: al_queue.c:445: _alSourceUnqueueBuffers: Assertion `tempqueue' failed.
At this point, the program receives SIGABRT.
In gdb, the back trace looks like this:
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 2458)]
0x4020be01 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4020be01 in kill () from /lib/i686/libc.so.6
#1 0x40580361 in pthread_kill () from /lib/i686/libpthread.so.0
#2 0x405806db in raise () from /lib/i686/libpthread.so.0
#3 0x4020ba68 in raise () from /lib/i686/libc.so.6
#4 0x4020d0d0 in abort () from /lib/i686/libc.so.6
#5 0x402049d1 in __assert_fail () from /lib/i686/libc.so.6
#6 0x4013fc00 in _alSourceUnqueueBuffers () from /usr/lib/libopenal.so.0
#7 0x40161ccb in scmtrue () from /usr/lib/libopenal.so.0
#8 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#9 0x000001bd in ?? ()
#10 0x40161dfb in scmtrue () from /usr/lib/libopenal.so.0
#11 0x09a12128 in ?? ()
#12 0xbffff4d0 in ?? ()
#13 0x40164540 in ?? () from /usr/lib/libopenal.so.0
#14 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#15 0x00000000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x00000000 in ?? ()
#18 0x40164540 in ?? () from /usr/lib/libopenal.so.0
#19 0x40164214 in ?? () from /usr/lib/libopenal.so.0
#20 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#21 0xbffff488 in ?? ()
#22 0x4013fc89 in alSourceUnqueueBuffers () from /usr/lib/libopenal.so.0
#23 0x00004001 in ?? ()
#24 0x00000001 in ?? ()
#25 0xbffff47c in ?? ()
#26 0x4012d503 in alSourceStop () from /usr/lib/libopenal.so.0
#27 0x080a8995 in _IO_stdin_used ()
#28 0xbffff4d0 in ?? ()
#29 0x0806c188 in checkmusic ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
The only close reference I can find to this is the following posting to the OpenAL group.
http://opensource.creative.com/pipermail/openal/2003-October/001556.html" target="_blank">http://opensource.creative.com/piperma....56.html
The appearance of the jmalloc ignoring allocations of zero bytes looks like a possible match.
Anyway, this may be an OpenAL bug but it may originate in the gish code.
For the record, I'm running Mandrake Cooker with Alsa 1.0.3 and OpenAL 0.0.6-14mdk.
If you need any more info, let me know. If you want to send me a debug version of the demo, I'm fine with that too.
Cheers,
Toby Haynes
./gish -nosound
disabling music and then restarting the demo with
./gish -sound
I'm thinking that either changing the music tune or restarting the current one triggers the bug.
The following is the output from the ./gish executable:
... (many other hash.c:395 lines)
[hash.c:395] failed read
[hash.c:395] failed read
[hash.c:395] failed read
jmalloc silently ignoring 0 alloc from al_queue.c 442
jmalloc silently ignoring 0 alloc from al_queue.c 443
gish: al_queue.c:445: _alSourceUnqueueBuffers: Assertion `tempqueue' failed.
At this point, the program receives SIGABRT.
In gdb, the back trace looks like this:
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 2458)]
0x4020be01 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0 0x4020be01 in kill () from /lib/i686/libc.so.6
#1 0x40580361 in pthread_kill () from /lib/i686/libpthread.so.0
#2 0x405806db in raise () from /lib/i686/libpthread.so.0
#3 0x4020ba68 in raise () from /lib/i686/libc.so.6
#4 0x4020d0d0 in abort () from /lib/i686/libc.so.6
#5 0x402049d1 in __assert_fail () from /lib/i686/libc.so.6
#6 0x4013fc00 in _alSourceUnqueueBuffers () from /usr/lib/libopenal.so.0
#7 0x40161ccb in scmtrue () from /usr/lib/libopenal.so.0
#8 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#9 0x000001bd in ?? ()
#10 0x40161dfb in scmtrue () from /usr/lib/libopenal.so.0
#11 0x09a12128 in ?? ()
#12 0xbffff4d0 in ?? ()
#13 0x40164540 in ?? () from /usr/lib/libopenal.so.0
#14 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#15 0x00000000 in ?? ()
#16 0x00000000 in ?? ()
#17 0x00000000 in ?? ()
#18 0x40164540 in ?? () from /usr/lib/libopenal.so.0
#19 0x40164214 in ?? () from /usr/lib/libopenal.so.0
#20 0x40161cc0 in scmtrue () from /usr/lib/libopenal.so.0
#21 0xbffff488 in ?? ()
#22 0x4013fc89 in alSourceUnqueueBuffers () from /usr/lib/libopenal.so.0
#23 0x00004001 in ?? ()
#24 0x00000001 in ?? ()
#25 0xbffff47c in ?? ()
#26 0x4012d503 in alSourceStop () from /usr/lib/libopenal.so.0
#27 0x080a8995 in _IO_stdin_used ()
#28 0xbffff4d0 in ?? ()
#29 0x0806c188 in checkmusic ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
The only close reference I can find to this is the following posting to the OpenAL group.
http://opensource.creative.com/pipermail/openal/2003-October/001556.html" target="_blank">http://opensource.creative.com/piperma....56.html
The appearance of the jmalloc ignoring allocations of zero bytes looks like a possible match.
Anyway, this may be an OpenAL bug but it may originate in the gish code.
For the record, I'm running Mandrake Cooker with Alsa 1.0.3 and OpenAL 0.0.6-14mdk.
If you need any more info, let me know. If you want to send me a debug version of the demo, I'm fine with that too.
Cheers,
Toby Haynes