[sldev] lltexturefetch race condition
Michael Schlenker
schlenk at uni-oldenburg.de
Thu May 7 12:02:41 PDT 2009
Rob Lanphier schrieb:
> In "Crash in lltexturefetch just after logging in"
> https://jira.secondlife.com/browse/VWR-12775
>
> Robin writes:
>> Ok its a race condition between the
>> LLTextureFetchWorker::callbackDecoded() and
>> LLTextureFetchWorker::doWork()
>>
>> mState == DECODE_IMAGE kicks off the decode and sets the state machine
>> to DECODE_IMAGE_UPDATE, this does nothing until the decoded flag is
>> set, this is set in LLTextureFetchWorker::callbackDecoded(), but as
>> soon as its set, the state machine moves on and in the event of a
>> failed decode it sets mFormattedImage=NULL and sets the state machine
>> back to INIT
>>
>> but in LLTextureFetchWorker::callbackDecoded we have already passed
>> the check for STATE!=DECODE_IMAGE_UPDATE so the code moves on and then
>> finds itsself for a NULL mFormattedImage
>>
>> Adding a 2nd
>>
>> if (mState != DECODE_IMAGE_UPDATE)
>>
>> { llwarns << "Decode callback for " << mID << " with state = " <<
>> mState << llendl; }
>>
>> after the
>>
>> mDecoded = TRUE;
>>
>> results in the 2nd warns message fireing every time mFormattedImage is
>> null here, the first warns *BEFORE* mDecoded-TRUE never fires so its a
>> race condition.
>>
>
> Based on my reading of things, this comment may have been overlooked.
The conclusion sounds correct.
> Couple of questions:
> 1. Does the comment above get us closer to a deeper fix for this problem?
> 2. Should we go ahead and apply the attached patches for this, even if
> they don't constitute a "real fix", because they do at least seem to
> keep us from crashing?
No crash is better than a crash.
A real fix would simply not rely on the current logic to get at the
image reference to decode some more or less unimportant info. If it
would fetch the discardLevel right after the decode as it does with
other info too and stash it somewhere for the callback to retrieve, the
crash would go away. Not sure where one could stash the info though, but
mFormattedImage is surely the wrong place.
Michael
More information about the SLDev
mailing list