Re: [AD] get_audio_stream_buffer

[Serge Semashko <serge@xxxxxxxxxx>]

Chris wrote:

> > First, looks like I have a broken gdb in my system, it does not show 
> > anything on 'info threads' command :(
>
> I also don't have any output when I try 'show threads'. Since I 
> reinstalled Gentoo, I also haven't gotten any messages about new threads 
> starting, which is probably related. Also related is probably that I 
> also get the message 'Using host libthread_db library 
> "/lib/libthread_db.so.1"' which I didn't before the reinstall.

Thanks for the hints, I have found a solution in gentoo forums and fixed 
this issue.

> > I also tried to run test program with ALSA driver (at last it is 
> > working in 4.1.15 WIP version) and it runs perfectly. I have run tests 
> > for several nights to be sure that it is not just a coincidence. 
> > Considering that this test also works fine in Windows, looks like the 
> > problem is in OSS support code and not in streams or mixer. That 
> > should help to locate the problem.
>
> It could also be a problem with ALSA's OSS driver for your card.

Examining this bug in gdb reveals the following information:

(gdb) bt
#0  _mix_some_samples (buf=1086511624, seg=42190, issigned=1) at 
src/mixer.c:1107
#1  0x08198475 in oss_update (threaded=1) at src/unix/uoss.c:176
#2  0x0819a4ce in bg_man_pthreads_threadfunc (arg=0x0) at 
src/unix/uthreads.c:100
#3  0x400eaa9c in start_thread () from /lib/libpthread.so.0
#4  0x40398d3a in clone () from /lib/libc.so.6
(gdb) up
#1  0x08198475 in oss_update (threaded=1) at src/unix/uoss.c:176
176     src/unix/uoss.c: No such file or directory.
        in src/unix/uoss.c
(gdb) inspect bufinfo
$1 = {fragments = 2097151, fragstotal = 8, fragsize = 2048, bytes = -1536}
(gdb)

Either it is a memory corruption bug during one of the loop iterations 
in 'oss_update' function or it is really ALSA's OSS driver bug. I use 
'snd-via82xx' driver (on both machines where I have tested this 
problem). I will add a check if these bad values (fragstotal > 
fragments) are returned immediately after ioctl call and test it today. 
Hunting for this bug is really very exhausting as is takes so much time 
to reproduce it :( So I'm sorry for the slow progress debugging it. But 
most likely it is not allegro problem and the next step will be digging 
into OSS driver code.