2

Given I've opened core file via lldb, how can I check which thread crashed?

$ lldb -c core.45583 -o 'bt all' | grep -A2 'thread #'
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fffc6b7641a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fffc6b75867 libsystem_kernel.dylib`mach_msg + 55
--
  thread #2, stop reason = signal SIGSTOP
    frame #0: 0x00007fffc6c65214 libsystem_pthread.dylib`start_wqthread
--
  thread #3, stop reason = signal SIGSTOP
    frame #0: 0x00007fffc6b7641a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007fffc6b75867 libsystem_kernel.dylib`mach_msg + 55
--
  thread #4, stop reason = signal SIGSTOP
    frame #0: 0x00007fffc6b7dc12 libsystem_kernel.dylib`__pselect + 10
    frame #1: 0x00007fffc6b7a815 libsystem_kernel.dylib`pselect$1050 + 82
--
  thread #5, stop reason = signal SIGSTOP
    frame #0: 0x00007fffc6bd368b libsystem_malloc.dylib`get_tiny_previous_free_msize + 59
    frame #1: 0x00007fffc6be83b6 libsystem_malloc.dylib`tiny_free_no_lock + 80
...
  thread #19, stop reason = signal SIGSTOP
    frame #0: 0x00007fffc6163b69 libobjc.A.dylib`objc_msgSend + 41
    frame #1: 0x00007fffb0d002a2 CFNetwork`HTTPResponseMessage::setResponseURL(__CFURL const*, unsigned char) + 66

As it seems all the threads have SIGSTOP.

Improve this question
1

It seems it should be the one with mach_msg_trap but looks like you'll need to do some hex dump hunting to recover the real call stack...

Improve this answer
  • Thanks for the reply. There are actually 2 threads with mach_msg_trap, how do you know which one and why? Which commands I should run to check that? – kenorb Oct 23 '17 at 13:44
  • I don't know; try to look further in the call stacks. Anyway, it's not really an RE question. – Igor Skochinsky♦ Oct 23 '17 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.