[sldev] A few call stacks from crash reports

[Philippe Bossut (Merov Linden)]

Hi Michael,

Yes, this is also what I found and my patch (attached to http://jira.secondlife.com/browse/VWR-12775) 
  is similar to yours.

I didn't apply it but I'm trying to determine the condition of the  
race condition, as, according to the dev who put that code together,  
that is *not* supposed to happen.

Doing research today, I think that the problem has been magnified by  
the newly introduced "caching of small texture" that Robin and myself  
have been working on last week: all the textures that trigger the bug  
are small (<= 600 bytes). Still digging though I think I'll have good  
news tonight or tomorrow :)

Cheers,
- Merov

On Apr 16, 2009, at 6:06 PM, Michael Schlenker wrote:

>
> Am 16.04.2009 um 00:43 schrieb Rob Lanphier:
>> We'd really love some help getting these crashing bugs figured out.
>> We'd like to be able to offer this version of the viewer in a much
>> more
>> prominent place, but obviously can't feel good about doing that
>> until we
>> get to the bottom of the crashing issues (at a minimum).
>>
>> Call stack #3:
>> [0] LLTextureFetchWorker::callbackDecoded [secondlife-bin
>> lltexturefetch.cpp:1302]
>> [1] LLTextureFetchWorker::DecodeResponder::completed [secondlife-bin
>> lltexturefetch.cpp:123]
>> [2] LLImageDecodeThread::ImageRequest::finishRequest [secondlife-bin
>> llimageworker.cpp:154]
>> [3] LLQueuedThread::processNextRequest [secondlife-bin
>> llqueuedthread.cpp:430]
>> [4] LLQueuedThread::run [secondlife-bin llqueuedthread.cpp:485]
>> [5] LLThread::staticRun [secondlife-bin llthread.cpp:78]
>> [6] apr_threadattr_guardsize_set [secondlife-bin unknownfile:0]
>> [7] Unknown [msvcr80.dll ]
>>
> Okay, some comments on this one.
>
> I see it with the OS X viewer too, just built from SVN.
>
> It crashes because mFormattedImage is a pretty NULL pointer inside
> CallbackDecoded(), but its alive and healthy outside in stack levels 1
> and 2 and 3 inside the request. The refcount is 1, which looks wrong
> from my cursory inspection.
>
> Not sure how it got there, but from what i can see the mFormattedImage
> pointer gets NULL'ed.
>
> I guess its a race condition between the Main thread that NULLs the
> mFormattedImage pointer of the request and the callback that accesses
> it for the discard level.
>
> This might fix it, but guess its not enough because there is still a
> race between the notNull() check and the call:
>
> Index: indra/newview/lltexturefetch.cpp
> ===================================================================
> --- indra/newview/lltexturefetch.cpp	(revision 2123)
> +++ indra/newview/lltexturefetch.cpp	(working copy)
> @@ -111,6 +111,7 @@
>  		DecodeResponder(LLTextureFetch* fetcher, const LLUUID& id,
> LLTextureFetchWorker* worker)
>  			: mFetcher(fetcher), mID(id), mWorker(worker)
>  		{
> +			
>  		}
>  		virtual void completed(bool success, LLImageRaw* raw, LLImageRaw*
> aux)
>  		{
> @@ -1299,12 +1300,18 @@
>  	if ((mRawImage.notNull() && mRawImage->getDataSize() > 0) &&
>  		(!mNeedsAux || (mAuxImage.notNull() && mAuxImage->getDataSize() >
> 0)))
>  	{
> -		mDecodedDiscard = mFormattedImage->getDiscardLevel();
> +		if (mFormattedImage.notNull()) {
> +			mDecodedDiscard = mFormattedImage->getDiscardLevel();
> +		}
>  // 		llinfos << mID << " : DECODE FINISHED. DISCARD: " <<
> mDecodedDiscard << llendl;
>  	}
>  	else
>  	{
> -		llwarns << "DECODE FAILED: " << mID << " Discard: " <<
> (S32)mFormattedImage->getDiscardLevel() << llendl;
> +		if (mFormattedImage.notNull()) {
> +			llwarns << "DECODE FAILED: " << mID << " Discard: " <<
> (S32)mFormattedImage->getDiscardLevel() << llendl;
> +		} else {
> +			llwarns << "DECODE FAILED: " << mID << llendl;
> +		}
>  		removeFromCache();
>  	}
>  // 	llinfos << mID << " : DECODE COMPLETE " << llendl;
>
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges