[sldev] A few call stacks from crash reports

[Philippe Bossut (Merov Linden)]

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