[sldev] Recurring snowglobe crash

[Steve Bennetts (Steve Linden)]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090529/1963fb80/attachment.pgp