Quite annoying assertion

Andrey_Zaytsev · August 8, 2011, 10:34pm

Hello everyone!
I'm very often getting this assertion when evaluating some sort of expressions:

Assertion failed: (!isNull() && "Cannot retrieve a NULL type pointer"), function getCommonPtr, file /SourceCache/lldb/lldb-69/llvm/tools/clang/include/clang/AST/Type.h, line 404.

This assertion fires every time I'm evaluating something like this: "[0x12345.. someSelector]". I'm stuck with it because I need values of this kind of expressions to display ns-collections.

Thanks for your consideration.

Enrico_Granata · August 8, 2011, 10:38pm

Would you be able to provide example commands that trigger this?
This looks like some of your types are not completed, but it’s hard to tell which ones and why without something reproducible

Andrey_Zaytsev · August 8, 2011, 11:59pm

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?

Enrico_Granata · August 9, 2011, 12:45am

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.

Do you mean you tried all other possible combinations (64-bit, not attaching by PID, …) and the only way to get the crash is “32-bit in simulator(which simulator? iOS?) attaching by PID”?

If so, trying to reproduce this consistently might take some effort. If, on the other side, this happens in other possible scenarios, I bet it is an incomplete type problem.
Which version of LLDB are you using?

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?

Would you be able to provide example commands that trigger this?
This looks like some of your types are not completed, but it’s hard to tell which ones and why without something reproducible

Hello everyone!
I’m very often getting this assertion when evaluating some sort of expressions:

Assertion failed: (!isNull() && “Cannot retrieve a NULL type pointer”), function getCommonPtr, file /SourceCache/lldb/lldb-69/llvm/tools/clang/include/clang/AST/Type.h, line 404.

This assertion fires every time I’m evaluating something like this: “[0x12345… someSelector]”. I’m stuck with it because I need values of this kind of expressions to display ns-collections.

Thanks for your consideration.

lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Thanks,

Enrico Granata

✆ 408.974.5572 | egranata@.com

lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Enrico Granata

✆ 408.974.5572 | egranata@.com

Greg_Clayton1 · August 9, 2011, 6:38pm

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

Topic		Replies	Views
Possible bug in the LLDB Python Scripting Example (And the API itself) LLDB	4	70	February 16, 2015
one more bug in evaluation LLDB	2	88	December 15, 2011
Stackoverflow crash when evaluating an invalid expression LLDB	1	131	February 28, 2019
Stackoverflow crash when evaluating an invalid expression LLDB	6	113	December 9, 2019
bytecode reader assertion failure LLVM Dev List Archives	3	77	February 25, 2007

Quite annoying assertion

Related Topics