[lldb-dev] Quite annoying assertion

[Greg Clayton]

On Aug 8, 2011, at 4:59 PM, Andrey Zaytsev wrote:

> I just got it. 
> 
> NSArray *arr = [NSArray array];
> 
> following code will trigger assertion:
> 
> SBValue res = frame.EvaluateExpression("[arr respondsToSelector:@selector(objectEnumerator)]");
> if (res.IsValid()) {
>     res.GetTypeName(); //  <-- here
> }
> 
> backtrace:
> #0  0x00007fff817aa9ce in __semwait_signal_nocancel ()
> #1  0x00007fff817aa8d0 in nanosleep$NOCANCEL ()
> #2  0x00007fff818073ce in usleep$NOCANCEL ()
> #3  0x00007fff81826a00 in abort ()
> #4  0x00007fff818139bc in __assert_rtn ()
> #5  0x00000001002e5f43 in lldb_private::ClangASTType::GetTypeNameForQualType ()
> #6  0x00000001002e60f1 in lldb_private::ClangASTType::GetConstTypeName ()
> #7  0x0000000100259bf9 in lldb_private::ValueObjectConstResult::GetTypeName ()
> #8  0x0000000100189607 in lldb::SBValue::GetTypeName ()
> #9  0x000000010006f29e in jetcidr::EvaluatedValue2LLDBValue (pair=@0x101f86a78, lldb_val=0x1034c5050) at ResponseFactory.h:52
> #10 0x000000010007b7cc in jetcidr::ResponseFactory::EvaluateExpression (this=0x103407910, pair=@0x101f86b20) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ResponseFactory.cpp:92
> #11 0x000000010006b8f1 in jetcidr::ProtobufHandler::HandleEvaluateExpression (this=0x1031001d0, req=@0x1034ade10) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ProtobufHandler.cpp:156
> #12 0x000000010006c2cf in jetcidr::ProtobufHandler::ProcessMessage (this=0x1031001d0, req=@0x101f86c50) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ProtobufHandler.cpp:236
> #13 0x000000010006c620 in __HandleHasBytesAvailable_block_invoke_0 (.block_descriptor=<value temporarily unavailable, due to optimizations>) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ProtobufHandler.cpp:261
> #14 0x00007fff8176cfbb in dispatch_barrier_sync_f ()
> #15 0x000000010006c42f in jetcidr::ProtobufHandler::HandleHasBytesAvailable (this=0x1031001d0, r_source=0x103100000) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ProtobufHandler.cpp:252
> #16 0x00000001000699b1 in __StartHandlingClient_block_invoke_05 (.block_descriptor=<value temporarily unavailable, due to optimizations>) at /Users/zajac/Projects/ULTIMATE/CIDR/LLDBProtobufFrontend/LLDBProtobufFrontend/src/ProtobufServer.cpp:76
> #17 0x00007fff817533f3 in _dispatch_source_invoke ()
> #18 0x00007fff817527b4 in _dispatch_queue_invoke ()
> #19 0x00007fff817528dc in _dispatch_queue_drain ()
> #20 0x00007fff81752734 in _dispatch_queue_invoke ()
> #21 0x00007fff817522de in _dispatch_worker_thread2 ()
> #22 0x00007fff81751c08 in _pthread_wqthread ()
> #23 0x00007fff81751aa5 in start_wqthread ()
> 
> This happened for me only in 32-bit mode when running app in simulator and attaching to process by pid.
> But(!): 
> 
> (lldb) p [arr respondsToSelector:@selector(objectEnumerator)]
> error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xffffffff).
> The process has been returned to the state before execution.
> 
> After this lldb won't crash.
> 
> What am I doing wrong?

This might be already fixed as of revision 137097. There was a case where the type might not be complete yet and code was added to "ClangASTType::GetConstTypeName ()" to complete the type. Does the top of tree still crash for you? 

So I tested the ability to run this expression and it indeed works as expected for i386 and x86_64. Some things to watch out for:
- "arr" might not be initialized and can contain garbage. If you set a breakpoint on a source line:

NSArray *arr = [NSArray array]; <-- stop here

Then "arr" contains a random value from what was previously on the stack and it can be anything. This is probably the reason for the crash when running the expression.

Let me know if the top of tree doesn't fix your issue.

Greg Clayton