[openal] OpenAL fails with OSS on FreeBSD

Yuri yuri at rawbw.com
Thu Dec 1 21:19:37 EST 2016


On 12/01/2016 18:06, Chris Robinson wrote:
> On 12/01/2016 05:34 PM, Yuri wrote:
>> It wasn't optimized when I debugged it. It definitely changes the value
>> outside its range.
>
> libc looks like it's optimized, which is where memset is and you say a 
> string is being changed. There's certainly something fishy going on. 
> If "OSS Default" is being changed, I wouldn't expect the
>
> [06:00:45.404 UTC] src/audio/audio.cpp:396 : Warning: Cannot open 
> output audio device "OSS Default"
>
> line to look like it does, as the device name string is clearly intact 
> after the alcOpenDevice call. Unless alcOpenDevice gets a different 
> copy of the string. If the pointer itself is getting changed by memset 
> (meaning it's overwriting the stack, and somehow doesn't crash), it 
> would be overwritten with 0s, likely NULL, which should result in an 
> (EE) message that it can't open /dev/dsp.
>
> What happens if you call alcOpenDevice(NULL) instead of passing in a 
> device name? 

No, when I call the toy program it works fine. It only breaks for me in 
the context of the larger Qt app - qTox. So I debugged the way it was 
called by qTox. libc is optimized, but this shouldn't matter. You need 
to look at the size passed to memset. It looks like memset sets memory 
outside the allocated range.

Another thing I can recommend is to run testcases under valgrind - its 
plugin memcheck. I am almost sure it will find problems.

Yuri


More information about the openal mailing list