• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Debugging with lldb causes crash, but not with gdb
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • Follow-Ups:
    • Re: Debugging with lldb causes crash, but not with gdb
      • From: Jim Ingham <email@hidden>
References: 
 >Debugging with lldb causes crash, but not with gdb (From: Rick Mann <email@hidden>)
 >Re: Debugging with lldb causes crash, but not with gdb (From: Jim Ingham <email@hidden>)

  • Prev by Date: Re: Debugging with lldb causes crash, but not with gdb
  • Next by Date: Re: Debugging with lldb causes crash, but not with gdb
  • Previous by thread: Re: Debugging with lldb causes crash, but not with gdb
  • Next by thread: Re: Debugging with lldb causes crash, but not with gdb
  • Index(es):
    • Date
    • Thread