Mixer / audio lookup on Sharp Zaurus

SDL Development
1

Heya. While working with SDL_mixer on the Sharp Zaurus handheld, I ran
into a lockup bug (mutex deadlock it seems). I first noticed this when
I changed from playing (with SDL_mixer that is) on “any channel” (i.e
channel -1) to specific channels. I never got any troubles when using
channel -1. Some info from gdb below:

Program received signal SIGINT, Interrupt.
0x401885c4 in nanosleep () from /lib/libc.so.6
(gdb) Quit
(gdb) bt
#0 0x401885c4 in nanosleep () from /lib/libc.so.6
#1 0x400d28e8 in nanosleep () from /lib/libpthread.so.0
#2 0x400d26d4 in sem_timedwait () from /lib/libpthread.so.0
#3 0x400d218c in sem_timedwait () from /lib/libpthread.so.0
#4 0x400ce1cc in pthread_mutex_lock () from /lib/libpthread.so.0
#5 0x400b51ec in SDL_mutexP (mutex=0xfffffffc) at SDL_sysmutex.c:133

#6 0x4008d7e0 in SDL_LockAudio_Default (audio=0x203d610) at SDL_audio.c:238
#7 0x4008dec0 in SDL_LockAudio () at SDL_audio.c:530
#8 0x400582b8 in _Mix_channel_done_playing (channel=0, lockaudio=1)
at mixer.c:109
#9 0x4005931c in Mix_PlayChannelTimed (which=0, chunk=0x420,
loops=-1073743052, ticks=-1073743040) at mixer.c:637
#10 0x02008364 in queuesam (chan=-4, sam=0) at sdlsound.c:257
#11 0x02006dc4 in FireShot () at hyperoid.c:1290
#12 0x02007568 in DrawPlayer () at hyperoid.c:1450
#13 0x020075fc in DrawObjects () at hyperoid.c:1469
#14 0x02007a38 in GameIteration () at hyperoid.c:1630
#15 0x02007ba0 in main (argc=-4, argv=0x0) at hyperoid.c:1689
#16 0x40104070 in __libc_start_main () from /lib/libc.so.6
(gdb)
#0 0x401885c4 in nanosleep () from /lib/libc.so.6
#1 0x400d28e8 in nanosleep () from /lib/libpthread.so.0
#2 0x400d26d4 in sem_timedwait () from /lib/libpthread.so.0
#3 0x400d218c in sem_timedwait () from /lib/libpthread.so.0
#4 0x400ce1cc in pthread_mutex_lock () from /lib/libpthread.so.0
#5 0x400b51ec in SDL_mutexP (mutex=0xfffffffc) at SDL_sysmutex.c:133
#6 0x4008d7e0 in SDL_LockAudio_Default (audio=0x203d610) at SDL_audio.c:238
#7 0x4008dec0 in SDL_LockAudio () at SDL_audio.c:530
#8 0x400582b8 in _Mix_channel_done_playing (channel=0, lockaudio=1)
at mixer.c:109
#9 0x4005931c in Mix_PlayChannelTimed (which=0, chunk=0x420,
loops=-1073743052, ticks=-1073743040) at mixer.c:637
#10 0x02008364 in queuesam (chan=-4, sam=0) at sdlsound.c:257
#11 0x02006dc4 in FireShot () at hyperoid.c:1290
#12 0x02007568 in DrawPlayer () at hyperoid.c:1450
#13 0x020075fc in DrawObjects () at hyperoid.c:1469
#14 0x02007a38 in GameIteration () at hyperoid.c:1630
#15 0x02007ba0 in main (argc=-4, argv=0x0) at hyperoid.c:1689
#16 0x40104070 in __libc_start_main () from /lib/libc.so.6
(gdb)
#5 0x400b51ec in SDL_mutexP (mutex=0xfffffffc) at SDL_sysmutex.c:133
133 if ( pthread_mutex_lock(&mutex->id) < 0 ) {
(gdb) p *mutex
Cannot access memory at address 0xfffffffc
(gdb) up
#6 0x4008d7e0 in SDL_LockAudio_Default (audio=0x203d610) at SDL_audio.c:238
238 SDL_mutexP(audio->mixer_lock);
(gdb) p *audio
$2 = {name = 0x400b7258 “dsp”, desc = 0x0,
OpenAudio = 0x40090d5c <DSP_OpenAudio>, ThreadInit = 0,
WaitAudio = 0x4009080c <DSP_WaitAudio>,
PlayAudio = 0x40090994 <DSP_PlayAudio>,
GetAudioBuf = 0x40090a98 <DSP_GetAudioBuf>, WaitDone = 0,
CloseAudio = 0x40090ab0 <DSP_CloseAudio>,
LockAudio = 0x4008d7ac <SDL_LockAudio_Default>,
UnlockAudio = 0x4008d7e4 <SDL_UnlockAudio_Default>, spec = {freq = 22050,
format = 32784, channels = 2 ‘\002’, silence = 0 ‘\000’, samples = 256,
padding = 514, size = 1024, callback = 0x400583ec <mix_channels>,
userdata = 0x0}, convert = {needed = 0, src_format = 0, dst_format = 0,
rate_incr = 0, buf = 0x0, len = 0, len_cvt = 0, len_mult = 0,
len_ratio = 0, filters = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
filter_index = 0}, enabled = 1, paused = 0, opened = 1,
fake_stream = 0x2041900 “(q\037@(q\037@?\003c?$??\t–”,
mixer_lock = 0x2040fc0, thread = 0x2042f10, threadid = 1026,
hidden = 0x203d6d0, free = 0x400906f0 <Audio_DeleteDevice>}
(gdb) p *audio->mixer_lock
$3 = {id = {__m_reserved = 0, __m_count = 0, __m_owner = 0xbf7ffc00,
__m_kind = 1, __m_lock = {__status = 0, __spinlock = 1}}}
(gdb) p audio->mixer_lock
$4 = (SDL_mutex *) 0x2040fc0

I’m guessing the weird pointer to the mutex in frame #5 is actually
some optimization issue rather than a bug (since it doesn’t actually
crash). It’s obviously a deadlock of some sort. BTW, I tried applying
Ryan’s mutex locking patch too to no avail.

And with that, I go to bed.–
[ Below is a random fortune, which is unrelated to the above message. ]
Q: How do you play religious roulette?
A: You stand around in a circle and blaspheme and see who gets
struck by lightning first.

2

And with that, I go to bed.

I don’t suppose you called LockAudio somewhere else and forgot to call
UnlockAudio to match it?

It’s also possible that I^Hwe screwed something up while ripping up the
lockaudio code in the past few days; can you see if a CVS checkout from
two weeks ago has this problem?

–ryan.

3

“Ryan C. Gordon” writes:

And with that, I go to bed.

I don’t suppose you called LockAudio somewhere else and forgot to call
UnlockAudio to match it?

I just use SDL_mixer and don’t actually do any low-level stuff myself.

It’s also possible that I^Hwe screwed something up while ripping up the
lockaudio code in the past few days; can you see if a CVS checkout from
two weeks ago has this problem?

Actually, this did happen with prior to the past few days. One thought

  • could it be related to recursive mutex locks (namely, them not
    working?). I had to go through hoops to get them detected - perhaps
    a mistake. I will try again today without recursive mutex lock code.–
    [ Below is a random fortune, which is unrelated to the above message. ]
    Pascal Users:
    The Pascal system will be replaced next Tuesday by Cobol.
    Please modify your programs accordingly.