So, adding that lock exposed a flaw in the logic resulting in a
deadlock. Below is the fix for that. The problem was that
LLTextureCache::update() was keeping the mutex protecting mReaders[] and
mWriters[] locked while calling completed() in the responders, however
readComplete() and writeComplete() (calls to which get triggered by the
responders) do their own locking of the mutex, triggering the deadlock.
There is no reason for the mutex to be locked while calling these
completed() functions.
-Steve
Index: lltexturecache.cpp
===================================================================
--- lltexturecache.cpp (revision 121571)
+++ lltexturecache.cpp (revision 121572)
@@ -779,6 +779,9 @@
}
}
+ unlockWorkers();
+
+ // call 'completed' with workers list unlocked (may call
readComplete() or writeComplete()
for (responder_list_t::iterator iter1 = completed_list.begin();
iter1 != completed_list.end(); ++iter1)
{
@@ -787,8 +790,6 @@
responder->completed(success);
}
- unlockWorkers();
-
return res;
}
Steve Bennetts wrote:
> We will be applying this patch next week, but if someone wants to play,
> I just discovered this major bug in lltexturefetch.cpp:
>
> void LLTextureFetchWorker::callbackDecoded(bool success, LLImageRaw*
> raw, LLImageRaw* aux)
> {
> + LLMutexLock lock(&mWorkMutex);
>
> ...
>
>
> The missing mutex lock here can cause all sorts of terrible artifacts.
> Don't know if this will fix everything, but it definitely addresses at
> least one of the crashes I have been seeing.
>
> -Steve
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
