Another update:
I disabled pthread cancelation on my filler thread, but keep my debugging procedure on the threads cancelation stack, until the thread exits by the intended means. The occasional termination of the thread still happens, and the back trace shows that it is coming from something deep in the ExtAudioFileRead API. No other threads can be accused of sending a cancel message, since cancel messages to this thread are now blocked. My guess is it's caused by some kind of uncaught exception in the ExtAudioFile API... maybe related to files played via AFP. My "fix" is to set a flag in my debug/cancelation procedure such that file playing is stopped, and I don't call ExtAudioFileDestroy latter on after the player is deallocated. This of course causes a memory leak, but it prevents my application for blocking indefinitely. The bug only come up once every few days, so the leak should be minor.
At this point, I am very confident that the problem is not in my code. Does it sound like something I should file a bug report for?
Ethan... _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
