Skip to content

Conversation

@cigumo
Copy link
Collaborator

@cigumo cigumo commented Nov 24, 2018

(also makes test 19 faster to trigger openal bugs faster)

The original problem: CrashIfClientProvidedBogusAudioBufferList
cocos2d#18948
is not happening anymore, but there's still a not very frequent issue
that makes OpenAL crash with a call stack like this.
AudioCache::readDataTask > alBufferData > CleanUpDeadBufferList

It happes more frequently when the device is "cold", which means after
half an hour of not using the device (locked).

I could not find the actual source code for iOS OpenAL, so I used the
macOS versions:
https://opensource.apple.com/source/OpenAL/OpenAL-48.7/Source/OpenAL/oalImp.cpp.auto.html

They seem to use CAGuard.h to make sure the dead buffer list
has no threading issues. I'm worried because the CAGuard code I found
has macos and win32 define but no iOS, so I'm not sure. I guess the
iOS version is different and has the guard.

I could not find a place in the code that's unprotected by the locks
except the InitializeBufferMap() which should not be called more than
once from cocos, and there's a workaround in AudioEngine-impl for it.

I reduced the occurence of the CleanUpDeadBufferList crash by moving
the guard in ~AudioCache to cover the alDeleteBuffers call.

(also makes test 19 faster to trigger openal bugs faster)

The original problem: CrashIfClientProvidedBogusAudioBufferList
cocos2d#18948
is not happening anymore, but there's still a not very frequent issue
that makes OpenAL crash with a call stack like this.
AudioCache::readDataTask > alBufferData > CleanUpDeadBufferList

It happes more frequently when the device is "cold", which means after
half an hour of not using the device (locked).

I could not find the actual source code for iOS OpenAL, so I used the
macOS versions:
https://opensource.apple.com/source/OpenAL/OpenAL-48.7/Source/OpenAL/oalImp.cpp.auto.html

They seem to use CAGuard.h to make sure the dead buffer list
has no threading issues. I'm worried because the CAGuard code I found
has macos and win32 define but no iOS, so I'm not sure. I guess the
iOS version is different and has the guard.

I could not find a place in the code that's unprotected by the locks
except the InitializeBufferMap() which should not be called more than
once from cocos, and there's a workaround in AudioEngine-impl for it.

I reduced the occurence of the CleanUpDeadBufferList crash by moving
the guard in ~AudioCache to cover the alDeleteBuffers call.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants