Comment #2 on issue 23579 by ramosian.glider: Potential thread unsafeness with CoreAudio http://code.google.com/p/chromium/issues/detail?id=23579
It looks like there is a real data race in CAMutex implementation. I don't know whether its source is publicly available, but I've found http://google.com/codesearch/p?hl=en&sa=N&cd=4&ct=rc#T8KXlji94bE/OpenAL-16/Source/PublicUtility/CAMutex.cpp&q=CAMutex%20coreaudio%20lang:c%2B%2B, which is very much alike (compared with `otool -t -V /System/Library/Frameworks/CoreAudio.framework/CoreAudio | less`). Can anyone confirm this? If the source is relevant, then CAMutex has got an "mOwner" data member which is read without taking a lock within CAMutex::Lock() and CAMutex::Unlock() to provide a fast path for the threads that do not own the lock (i.e. CAMutex::Lock() can be called twice within a single thread, and CAMutex::Unlock() can be called from a thread that didn't call CAMutex::Lock()). ThreadSanitizer reports a race on this data member. However, the race is benign on x86, because mOwner is written under a lock and can't be corrupted in a way it triggers the fast path, so we should definitely suppress it. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ Automated mail from issue updates at http://crbug.com/ Subscription options: http://groups.google.com/group/chromium-bugs -~----------~----~----~----~------~----~------~--~---
