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: Rick Mann <email@hidden>
- Date: Fri, 21 Oct 2011 16:01:31 -0700
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
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'.
FWIW, I'm using LLDB-76. Also FWIW, 'po self' complains "error: use of undeclared identifier 'self'" (before the crash).
--
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