[sldev] Fw: Question/possible bug with on LLTextureFetch mutex use

[Bill Windwalker]

I have not seen that in the debug consol how long did this last ?
and what was you doing at that time that is happen ?

 


----- Forwarded Message ----
From: Vex Streeter <vexstreeter at gmail.com>
To: sldev at lists.secondlife.com
Sent: Friday, September 25, 2009 1:24:25 PM
Subject: [sldev] Question/possible bug with on LLTextureFetch mutex use

I've been reading the texture cache code for the last week or so, and I 
see something that I don't quite understand - looks like a bug to me, 
but I'm no expert on this code so I'm not comfortable enough to generate 
a jira entry:

// lltexturefetch.cpp (current snowglobe, svn 2574) line 1471-
void LLTextureFetch::addToNetworkQueue(LLTextureFetchWorker* worker)
{
    LLMutexLock lock(&mNetworkQueueMutex);
    if (mRequestMap.find(worker->mID) != mRequestMap.end())
    {
        // only add to the queue if in the request map
        // i.e. a delete has not been requested
        mNetworkQueue.insert(worker->mID);
    }
    for (cancel_queue_t::iterator iter1 = mCancelQueue.begin();
        iter1 != mCancelQueue.end(); ++iter1)
    {
        iter1->second.erase(worker->mID);
    }
}

Most accesses to mRequestMap are protected by locking mQueueMutex, but I 
don't see how that lock could be held here - addToNetworkQueue is called 
by LLTextureFetchWorker::doWork, which only holds mWorkMutex.  So my 
questions are:
1. Is mQueueMutex actually held somehow here, making it safe to call 
find() and end() on mRequestMap?
2. or are find() and end() somehow safe to invoke without being locked?  
Seems unlikely given the semantics of the usual std::map<> 
implementation and that the nearby getWorker appears to always be called 
with mQueueMutex held.

The failure mode would be find()==end() when it really is present, 
leading to a request that never got added to the network queue and never 
got canceled (e.g. a texture that isn't retrieved?).  mRequestMap is an 
std:map, which is a non-trivial datastructure - it isn't much of a 
stretch to imagine situations where the find() gets lost in the tree 
while an insert is splitting (or even worse, rebalancing - I don't know 
if std:map rebalances)

Hoping this is useful.  Cheers,
    Vex
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090926/c0d92213/attachment.htm