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

Thickbrick Sleaford (JIRA) no-reply at lindenlab.cascadeo.com
Tue Jan 26 07:20:32 PST 2010

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

Thickbrick Sleaford commented on SNOW-434:

Wouldn't this patch potentially allow the worker to be removed from mRequestMap between the two locks, leading to adding the worker to mNetworkQueue without being in mRequestMap?

I think a lock on mQueueMutex should be held throughout the length of addToNetworkQueue. To prevent lock order problems, it should probably be done before locking mNetworkQueueMutex.

> 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
>         Attachments: SNOW-434.patch
> 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