Re: Debugging with lldb causes crash, but not with gdb
Re: Debugging with lldb causes crash, but not with gdb
- Subject: Re: Debugging with lldb causes crash, but not with gdb
- From: Jim Ingham <email@hidden>
- Date: Fri, 21 Oct 2011 16:24:35 -0700
On Oct 21, 2011, at 4:01 PM, Rick Mann wrote:
>
> On Oct 21, 2011, at 15:48 , Jim Ingham wrote:
>
>> Does it crash into Xcode, so that you can get a backtrace? If so, then do:
>>
>> (lldb) thread backtrace all
>
> I can do this after the crash, and I get:
>
> (lldb) thread backtrace all
> * thread #1: tid = 0x2c03, 0x000028b3 MyApp`start + 35, stop reason = EXC_BAD_ACCESS (code=1, address=0xe390cb88)
> frame #0: 0x000028b3 MyApp`start + 35
This looks like something went wrong with calling some function by hand in the debugger. Probably this is the result of evaluating a data formatter.
>
> thread #2: tid = 0x3003, 0x9aa1b382 libSystem.dylib`kevent + 10
> frame #0: 0x9aa1b382 libSystem.dylib`kevent + 10
> frame #1: 0x0232c373 libdispatch.dylib`_dispatch_mgr_invoke + 918
> frame #2: 0x0232acd0 libdispatch.dylib`_dispatch_mgr_thread + 53
>
> thread #3: tid = 0x3103, 0x01c945bb libobjc.A.dylib`objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*>, objc::DenseMapInfo<unsigned long> >::LookupBucketFor(objc_object* const&, std::pair<objc_object*, unsigned long>*&) const + 103
> frame #0: 0x01c945bb libobjc.A.dylib`objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*>, objc::DenseMapInfo<unsigned long> >::LookupBucketFor(objc_object* const&, std::pair<objc_object*, unsigned long>*&) const + 103
> frame #1: 0x01c94532 libobjc.A.dylib`objc::DenseMap<objc_object*, unsigned long, true, objc::DenseMapInfo<objc_object*>, objc::DenseMapInfo<unsigned long> >::erase(objc_object* const&) + 32
> frame #2: 0x01c934db libobjc.A.dylib`objc_clear_deallocating + 194
> frame #3: 0x01c88f0d libobjc.A.dylib`objc_destructInstance + 64
> frame #4: 0x01ea08fb CoreFoundation`CFRelease + 1339
> frame #5: 0x018586a4 CoreLocation`CLConnectionMessage::~CLConnectionMessage() + 26
> frame #6: 0x0185896f CoreLocation`__setEventHandler_block_invoke_0 + 294
> frame #7: 0x02303cb4 libxpc_sim.dylib`__XPC_CONNECTION_EVENT_HANDLER_CALLOUT__ + 52
> frame #8: 0x02306113 libxpc_sim.dylib`_xpc_connection_recv_message + 650
> frame #9: 0x02306bb7 libxpc_sim.dylib`_xpc_connection_wakeup_recv + 199
> frame #10: 0x02306a5e libxpc_sim.dylib`_xpc_connection_wakeup2 + 1598
> frame #11: 0x02306c89 libxpc_sim.dylib`_xpc_connection_wakeup + 101
> frame #12: 0x0232f42c libdispatch.dylib`_dispatch_source_invoke + 719
> frame #13: 0x0232bd36 libdispatch.dylib`_dispatch_queue_invoke + 61
> frame #14: 0x0232be8f libdispatch.dylib`_dispatch_queue_drain + 236
> frame #15: 0x0232bd28 libdispatch.dylib`_dispatch_queue_invoke + 47
> frame #16: 0x0232be8f libdispatch.dylib`_dispatch_queue_drain + 236
> frame #17: 0x0232bd28 libdispatch.dylib`_dispatch_queue_invoke + 47
> frame #18: 0x0232be8f libdispatch.dylib`_dispatch_queue_drain + 236
> frame #19: 0x0232bd28 libdispatch.dylib`_dispatch_queue_invoke + 47
> frame #20: 0x0232b4af libdispatch.dylib`_dispatch_worker_thread2 + 229
> frame #21: 0x9aa1a781 libSystem.dylib`_pthread_wqthread + 390
>
> thread #4: tid = 0x3203, 0x9a9f4afa libSystem.dylib`mach_msg_trap + 10
> frame #0: 0x9a9f4afa libSystem.dylib`mach_msg_trap + 10
> frame #1: 0x9a9f5267 libSystem.dylib`mach_msg + 68
> frame #2: 0x01f6813a CoreFoundation`__CFRunLoopServiceMachPort + 186
> frame #3: 0x01ecb605 CoreFoundation`__CFRunLoopRun + 1445
> frame #4: 0x01ecadb4 CoreFoundation`CFRunLoopRunSpecific + 212
> frame #5: 0x01ecaccb CoreFoundation`CFRunLoopRunInMode + 123
> frame #6: 0x0397c220 WebCore`RunWebThread(void*) + 560
> frame #7: 0x9aa22259 libSystem.dylib`_pthread_start + 345
>
> thread #5: tid = 0x3303, 0x9aa18dd0 libSystem.dylib`mach_absolute_time
> frame #0: 0x9aa18dd0 libSystem.dylib`mach_absolute_time
> frame #1: 0x01ecb6be CoreFoundation`__CFRunLoopRun + 1630
> frame #2: 0x01ecadb4 CoreFoundation`CFRunLoopRunSpecific + 212
> frame #3: 0x01ecaccb CoreFoundation`CFRunLoopRunInMode + 123
> frame #4: 0x0021de40 Foundation`+[NSURLConnection(Loader) _resourceLoadLoop:] + 398
> frame #5: 0x0012f4e6 Foundation`-[NSThread main] + 76
> frame #6: 0x0012f457 Foundation`__NSThread__main__ + 1258
> frame #7: 0x9aa22259 libSystem.dylib`_pthread_start + 345
>
> thread #6: tid = 0x3403, 0x9aa2a79c libSystem.dylib`_pthread_exit
> frame #0: 0x9aa2a79c libSystem.dylib`_pthread_exit
>
> thread #7: tid = 0x3503, 0x9aa13ac6 libSystem.dylib`select$DARWIN_EXTSN + 10
> frame #0: 0x9aa13ac6 libSystem.dylib`select$DARWIN_EXTSN + 10
> frame #1: 0x01efc7fb CoreFoundation`__CFSocketManager + 939
> frame #2: 0x9aa22259 libSystem.dylib`_pthread_start + 345
>
>
>> and put that in the bug. Also, stop somewhere before the crash if you can, and do:
>>
>> (lldb) log enable -f/tmp/lldb-log.txt step process expr
>
> When I try this command (before the crash), it complains:
>
> error: Invalid log channel 'step'.
Yeah, sorry, typo on my part. Should be:
(lldb) log enable -f /tmp/lldb-log.txt lldb step process expr
And actually we probably don't need the process logs, since this is just an expression going bad somehow. Just try:
(lldb) log enable -f /tmp/lldb-log.txt lldb step expr
BTW, you can get a list of all the available log channels with:
(lldb) log list
Can you stop somewhere without many complex locals (main is a good choice) and turn this log on. You should be able to continue from there to hit the problematic breakpoint, and then we'll be able to capture the logs for the data formatter evaluation that is causing the problem.
Thanks,
Jim
>
> FWIW, I'm using LLDB-76. Also FWIW, 'po self' complains "error: use of undeclared identifier 'self'" (before the crash).
>
Yes, that's not surprising. The thread you are looking at is not at the frame where you stopped anymore, it is at the frame where the function expression calling went bad. And that frame has no "self" local.
Jim
> --
> Rick
>
>>
>> and then run your session. When you crash, take that log file and the "thread backtrace" output, and file a bug report containing those.
>>
>> Jim
>>
>> On Oct 21, 2011, at 2:55 PM, Rick Mann wrote:
>>
>>> I'm not sure how to write up this bug report. I can put a breakpoint in my code, and if it's triggered and then I continue, the app immediately crashes when debugged under lldb, but runs just fine under gdb.
>>>
>>> --
>>> Rick
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Xcode-users mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden