Oh no its still happening, thanks to Opensource Obscure for the back traces. This time its a different interaction to SNOW-196. It seems this is a less common deadlock for most people but there are a few still getting it and Opensource seems to get it very repeatably.
What appears to be happening is that two worker threads are running on the same image, one is doing a LLImageDecodeThread::Responder::Complete() and the other is trying to start a new decode via LLTextureFetch::doWork(). So i guess this situation can occur after you have decoded one discard level and new data has appeared and another discard level has been achieved so a new decode has been started. When then combined with a specific test on the main thread we get a 3 way deadlock :- Thread 1 LLTextureFetch::getRequestFinished() - Locking mQueueMutex Spinning on mWorkMutex Thread 3 LLImageDecodeThread::Responder::Complete() Locking LLThread->mRunCondition Spinningon mQueueMutex Thread 5 LLTextureFetch::doWork() Locking mWorkMutex Locking mCreationMutex Spinning On LLThread->mRunCondition Threads 3 and 5 are both ending up with a LLThread that is instanced as a LLImageDecodeThread (with the same this pointer for #3 and #5) so the LLThread->mRunCondition lock is locking those two. I would have not though that threads 3 and 5 should be running at the same time on the same LLThread * ? why isn't the mRunCondition mutext locking that? Any comments? _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
