[JIRA] Commented: (SNOW-434) Unsafe threaded operation in lltexturefetch.cpp can result in unsatisfied texture fetch requests and possible memory corruption

Vex Streeter (JIRA) no-reply at lindenlab.cascadeo.com
Thu Jan 14 06:28:32 PST 2010

    [ http://jira.secondlife.com/browse/SNOW-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159553#action_159553 ] 

Vex Streeter commented on SNOW-434:

FWIW, I've been running without deadlocks addToNetworkQueue looking like:
bool stillthere = (mRequestMap.find() != mRequestmap.end());

LLMutexLock lock(&mNetworkQueueMutex);
if(stillthere) { 

The bool keeps the lock order matching other uses.

> Unsafe threaded operation in lltexturefetch.cpp can result in unsatisfied texture fetch requests and possible memory corruption
> -------------------------------------------------------------------------------------------------------------------------------
>                 Key: SNOW-434
>                 URL: http://jira.secondlife.com/browse/SNOW-434
>             Project: 6. Second Life Snowglobe - SNOW
>          Issue Type: Bug
>          Components: Graphics 
>    Affects Versions: Snowglobe 1.3
>         Environment: snowglobe trunk 3087, multi-core cpu with use multiple threads enabled
>            Reporter: Vex Streeter
>            Assignee: Merov Linden
>            Priority: Major
>             Fix For: Snowglobe 1.3
> LLTextureFetch::addToNetworkQueue(..)  (in lltexturefetch.cpp line 1473) locks mNetworkQueue (which is good), but doesn't lock mQueueMutex.  mQueueMutex guards access to mRequestMap, which is accessed in the next line.  While the find operation used isn't destructive, mRequestMap is a STL map, which is a non-trivial (tree-like) datastructure that attempts to maintain a balanced internal organization.  An unlocked find while another thread is doing an add could result in incorrectly believing that the texture request had been removed (leading to textures never getting loaded).  It is conceivable that a find/delete combination could result in dangling references and memory corruption - but it would depend on the specific implementation of the map_t structure.
> A bit of experimentation indicates that the lock on mQueueMutex isn't held by anyone in the stack, but is sometimes held by someone else - this indicates that collisions are, in fact, happening.  It is a more difficult exercise to determine how bad the collisions are.
> I suggest it is probably simpler to add a lock around the find, and then add to the network queue.
> Note that I originally reported this as a potential issue on the main viewer branch on sl-dev, but didn't have the time to get a build environment set up to confirm that it really was a problem.   I do still believe that the same problem exists there.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.secondlife.com/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the Jira-notify mailing list