FigReadWriteLockLockForRead and MTAudioProcessingTap crash

Question

Created Jun ’15

Replies 1

Boosts 0

Participants 2

My users are experiencing crashes in CoreMedia's FigReadWriteLockLockForRead function and I am unable to reproduce the crash.

The stack trace of the crashed thread contains MTAudioProcessingTap, which I am using to process audio coming from multiple video tracks in an AVMutableComposition:

Thread: RemoteClientNotifyQueue

0 libsystem_pthread.dylib _pthread_mutex_lock

1 CoreMedia FigReadWriteLockLockForRead

2 MediaToolbox MTAudioProcessingTapCallbacksServer_NotificationIsPending

3 MediaToolbox MTAudioProcessingTapCallbacks_server

Has anyone seen this issue before, or can point me in the right direction for debugging it?

Boost

Answer 1

wingnut OP

Sep ’16

I get this same crash & stack trace occastionally in one of our audio playback apps. Same setup by the look of your trace - we're using an audio tap for dynamic range compression.

I've never gotten to the bottom of it, although recently I've noticed a few times in the log that in another thread is trying to decode PNG data, I'm pretty sure this only happens when a new songs starts playback (loading the song's cover art from the metadata embedded in the audio file).

So, perhaps the thread loading the cover art is obtaining an exclusive lock on the file? Wild guess...

0