Hi, As it happened, I was logging PJIRA records with comments to cover some of those stack trace (the ones I investigated).
Note that there's a "non-crashing" bug that I'm also investigating as it was mentioned to me on IRC yesterday and I was able to repro it: - https://jira.secondlife.com/browse/VWR-12811 : everything renders "gray" . See the JIRA for specifics My comments on the stack trace here under: On Apr 15, 2009, at 3:43 PM, Rob Lanphier wrote: > call stack #1: > [0] usleep$NOCANCEL$UNIX2003 [libsystem.b.dylib unknown] > [1] abort [libsystem.b.dylib unknown] > [2] 0x9080f000 [libstdc++.6.dylib unknown] > [3] __gxx_personality_v0 [libstdc++.6.dylib unknown] > [4] std::terminate() [libstdc++.6.dylib unknown] > [5] std::type_info::~type_info() [libstdc++.6.dylib unknown] > [6] LLMenuItemBranchGL::getChildView(std::basic_string, > std::allocator > > const&, int, int) const [com.secondlife.indra.viewer unknown] > [7] LLView::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [8] LLView::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [9] LLPanel::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [10] LLInventoryPanel* LLView::getChild(std::basic_string, > std::allocator > const&, int, int) const [com.secondlife.indra.viewer > unknown] > [11] LLInventoryView::~LLInventoryView() [com.secondlife.indra.viewer > unknown] > [12] LLView::~LLView() [com.secondlife.indra.viewer unknown] > [13] LLFloaterView::~LLFloaterView() [com.secondlife.indra.viewer > unknown] > [14] LLView::~LLView() [com.secondlife.indra.viewer unknown] > [15] LLRootView::~LLRootView() [com.secondlife.indra.viewer unknown] > [16] LLViewerWindow::shutdownViews() [com.secondlife.indra.viewer > unknown] > [17] LLAppViewer::cleanup() [com.secondlife.indra.viewer unknown] > [18] main [com.secondlife.indra.viewer unknown] > [19] _start [com.secondlife.indra.viewer unknown] > [20] start [com.secondlife.indra.viewer unknown] That one is new to me. Someone has repro steps? > Call stack #2: > [0] LLError::crashAndLoop [secondlife-bin llerror.cpp:1214] > [1] LLError::Log::flush [secondlife-bin llerror.cpp:1138] > [2] LLVertexBuffer::setupVertexBuffer [secondlife-bin > llvertexbuffer.cpp:1132] > [3] LLVertexBuffer::setBuffer [secondlife-bin llvertexbuffer.cpp:1117] > [4] LLRenderPass::pushBatch [secondlife-bin lldrawpool.cpp:505] > [5] LLRenderPass::pushBatches [secondlife-bin lldrawpool.cpp:457] > [6] LLRenderPass::renderTexture [secondlife-bin lldrawpool.cpp:448] > [7] LLDrawPoolSimple::render [secondlife-bin lldrawpoolsimple.cpp:147] > [8] LLPipeline::renderGeom [secondlife-bin pipeline.cpp:2641] > [9] display [secondlife-bin llviewerdisplay.cpp:802] > [10] LLAppViewer::mainLoop [secondlife-bin llappviewer.cpp:938] > [11] WinMain [secondlife-bin llappviewerwin32.cpp:193] > [12] __tmainCRTStartup [secondlife-bin crtexe.c:589] > [13] Unknown [kernel32.dll ] > [14] Unknown [ntdll.dll ] > [15] Unknown [ntdll.dll ] This one was first reported by Philip and I was able to repro. Also someone on IRC mentioned that same issue to me yesterday. JIRA: https://jira.secondlife.com/browse/VWR-12827 The skinny: this is *not* an http-texture specific bug. I get that same crash using the trunk build or any 1.24 code base. Doesn't repro with 1.23 (to the relief of QA...). > 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 ] That one seems to be Mac specific and I was able to repro and step through it. JIRA: - https://jira.secondlife.com/browse/VWR-12811 - https://jira.secondlife.com/browse/VWR-12775 I know, that's 2 JIRA but I logged them thinking that was 2 different bugs. It's not. Note that I have a patch to avoid the crash condition but, after talking to bao, we decided not to commit the patch so that we can understand *why* we get into that state (we should *not* get to that decoder code part with an unexisting image...). I'm tracking that one down as it is clearly an http-texture bug. > Call stack #4: > [0] Curl_llist_insert_next [secondlife-bin unknownfile:0] > [1] Curl_hash_add [secondlife-bin unknownfile:0] > [2] Curl_cache_addr [secondlife-bin unknownfile:0] > [3] curl_getdate [secondlife-bin unknownfile:0] > [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] > [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] > [6] Unknown [msvcr80.dll ] > [7] Unknown [msvcr80.dll ] > [8] Unknown [kernel32.dll ] > [9] Unknown [msvcr80.dll ] > Call stack #5: > 0] Curl_llist_insert_next [secondlife-bin unknownfile:0] > [1] Curl_hash_add [secondlife-bin unknownfile:0] > [2] Curl_cache_addr [secondlife-bin unknownfile:0] > [3] curl_getdate [secondlife-bin unknownfile:0] > [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] > [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] > [6] Unknown [msvcr80.dll ] > [7] Unknown [msvcr80.dll ] > [8] Unknown [ntdll.dll ] > [9] Unknown [ntdll.dll ] Nice to see those Curl crashers again. I haven't experienced them in a while though (too busy crashing before that I guess...). Not logged yet though. > Call stack #6: > 0] semaphore_wait_signal_trap [libsystem.b.dylib unknown] > [1] LLQueuedThread::updateQueue(unsigned) [com.secondlife.indra.viewer > unknown] > [2] LLImageDecodeThread::update(unsigned) [com.secondlife.indra.viewer > unknown] > [3] LLAppViewer::mainLoop() [com.secondlife.indra.viewer unknown] > [4] main [com.secondlife.indra.viewer unknown] > [5] _start [com.secondlife.indra.viewer unknown] > [6] start [com.secondlife.indra.viewer unknown] I think this is another symptom of your #3. I could track that the worker can be in a weird state and get the decoder to crash or not (most of the time, not). We basically have those 2 possible stack trace when crashing in that state. Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
