[openal] OpenAL fails with OSS on FreeBSD
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.
More information about the openal