Ah, yes... this could actually be valid, we should eliminate the assert. I added it when I was trying to track down the problem and now understand why it happens. (There is an early exit in LLTextureFetchWorker::doWork() that can cause an abort while decoding. This is desired behavior, and is safe.)
I'll fix this in the internal http-texture branch. -Steve Philippe Bossut (Merov Linden) wrote: > Hi Steve, > > I looked into the crash reporter for snowglobe and saw the following > traceback 4 times (out of 12 crashers): > > [0] LLError::crashAndLoop > [1] LLError::Log::flush > [2] LLTextureFetchWorker::~LLTextureFetchWorker > [3] LLTextureFetchWorker::`scalar deleting destructor' > [4] LLWorkerThread::update > * e:/w-sweeper/linden/indra/llcommon/llworkerthread.cpp:112 > [5] LLTextureFetch::update > * e:/w-sweeper/linden/indra/newview/lltexturefetch.cpp:1589 > [6] LLAppViewer::cleanup > * e:/w-sweeper/linden/indra/newview/llappviewer.cpp:1339 > [7] LLAppViewerWin32::cleanup > * e:/w-sweeper/linden/indra/newview/llappviewerwin32.cpp:363 > [8] __tmainCRTStartup > [9] kernel32.dll > > > The traceback is triggered by the > "LLTextureFetchWorker::~LLTextureFetchWorker: ASSERT (mDecodeHandle == > 0)". Interestingly, it always happens when the destructor is called > from LLAppViewerWin32::cleanup(). > > Also, it happens to different residents on different regions so it > doesn't appear to be context specific. > > I logged http://jira.secondlife.com/browse/VWR-13766 to track the issue. > > Cheers, > - Merov
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
