获取任意线程调用栈的那些事
2016-08-29 09:51
351 查看
BSBacktraceLogger 是一个轻量级的框架,可以获取任意线程的调用栈,开源在我的 GitHub,建议下载下来结合本文阅读。
我们知道
最简单、自然的想法就是利用
这篇文章的重点不是介绍获取调用栈的细节,而是在实现过程中的遇到的诸多问题和尝试过的解决方案。有的方案也许不能解决问题,但在思考的过程中能够把知识点串联起来,在我看来这才是本文最大的价值。
在介绍后续知识之前,有必要介绍一下调用栈的相关背景知识。
上图表示了一个栈,它分为若干栈帧(frame),每个栈帧对应一个函数调用,比如蓝色的部分是
可以看到栈帧由三部分组成:函数参数,返回地址,帧内的变量。举个例子,在调用
Stack Pointer(栈指针)表示当前栈的顶部,由于大部分操作系统的栈向下生长,它其实是栈地址的最小值。根据之前的解释,Frame Pointer 指向的地址中,存储了上一次 Stack Pointer 的值,也就是返回地址。
在大多数操作系统中,每个栈帧还保存了上一个栈帧的 Frame Pointer,因此只要知道当前栈帧的 Stack Pointer 和 Frame Pointer,就能知道上一个栈帧的 Stack Pointer 和 Frame Pointer,从而递归的获取栈底的帧。
显然当一个函数调用结束时,它的栈帧就不存在了。
因此,调用栈其实是栈的一种抽象概念,它表示了方法之间的调用关系,一般来说从栈中可以解析出调用栈。
我们以
首先主线程也是线程,就得按照线程基本法来办事。线程基本法说的是首先要把线程运行起来,然后(如果有必要,比如主线程)启动 runloop 进行保活。我们知道 runloop 的本质就是一个死循环,在循环中调用多个函数,分别判断 source0、source1、timer、dispatch_queue 等事件源有没有要处理的内容。
和 UI 相关的事件都是 source0,因此会执行
假设我们使用
总而言之,一切涉及到 runloop,或者需要等待
信号其实是一种软中断,也是由系统的中断处理程序负责处理。在处理信号时,操作系统会保存正在执行的上下文,比如寄存器的值,当前指令等,然后处理信号,处理完成后再恢复执行上下文。
因此从理论上来说,信号可以强制让目标线程停下,处理信号再恢复。一般情况下发送信号是针对整个进程的,任何线程都可以接受并处理,也可以用
信号的处理可以用
比如我们运行程序后按下
遗憾的是,使用
答案是肯定的,首先系统提供了
对于每一个线程,可以用
在
在项目中,调用栈存储在
接下来的任务就是根据栈帧的 Frame Pointer 获取到这个函数调用的符号名。
根据 Frame Pointer 找到函数调用的地址
找到 Frame Pointer 属于哪个镜像文件
找到镜像文件的符号表
在符号表中找到函数调用地址对应的符号名
这实际上都是 C 语言编程问题,我没有相关经验,不过好在有前人的研究成果可以借鉴。感兴趣的读者可以直接阅读源码。
再次 Google 无果后,我找到了 GNUStep-base 的源码,下载了 1.24.9 版本,其中包含了 Foundation 库的源码,我不能确保现在的 NSThread 完全采用这里的实现,但至少可以从
pthread 是什么
NSThread 如何封装 pthread
pthread 中的字母 p 是 POSIX 的简写,POSIX 表示 “可移植操作系统接口(Portable Operating System Interface)”。
每个操作系统都有自己的线程模型,不同操作系统提供的,操作线程的 API 也不一样,这就给跨平台的线程管理带来了问题,而 POSIX 的目的就是提供抽象的 pthread 以及相关 API,这些 API 在不同操作系统中有不同的实现,但是完成的功能一致。
Unix 系统提供的
内核线程和 pthread 的转换(也即是
说 NSThread 封装了 pthread 并不是很准确,NSThread 内部只有很少的地方用到了 pthread。NSThread 的
甚至于 NSThread 都没有存储新建 pthread 的
另一处用到 pthread 的地方就是 NSThread 在退出时,调用了
而它仅仅是一个封装,根据线程获取到 runloop,真正调用的还是 NSRunloop 的方法:
这些信息将组成一个
一种思路是利用
很神奇的发现系统居然会发送一个通知,通知名不对外提供,但是可以通过监听所有通知名的方法得知它的名字:
一般 NSThread 使用
可见,这种方案并不现实,因为之前已经解释过,
回顾问题发现,我们需要的是一个联系 NSThread 对象和内核 thread 的纽带,也就是说要找到 NSThread 对象的某个唯一值,而且内核 thread 也具有这个唯一值。
观察一下 NSThread,它的唯一值只有对象地址,对象序列号(Sequence Number) 和线程名称:
地址分配在堆上,没有使用意义,序列号的计算没有看懂,因此只剩下 name。幸运的是 pthread 也提供了一个方法
这里的 np 表示 not POSIX,也就是说它并不能跨平台使用。
于是解决方案就很简单了,对于 NSThread 参数,把它的名字改为某个随机数(我选择了时间戳),然后遍历 pthread 并检查有没有匹配的名字。查找完成后把参数的名字恢复即可。
好在我们还可以迂回解决问题: 事先获得主线程的
上述方案要求我们在主线程中执行代码从而获得
完成一个技术项目往往最大的收获不是最后的结果,而是实现过程中的思考。这些走过的弯路加深了对知识体系的理解。
KSCrash
深入理解RunLoop
iOS中线程Call Stack的捕获和解析(一)、iOS中线程Call Stack的捕获和解析(二)
我们知道
NSThread有一个类方法
callstackSymbols可以获取调用栈,但是它输出的是当前线程的调用栈。在利用 Runloop 检测卡顿时,子线程检测到了主线程发生卡顿,需要通过主线程的调用栈来分析具体是哪个方法导致了阻塞,这时系统提供的方法就无能为力了。
最简单、自然的想法就是利用
dispatch_async或
performSelectorOnMainThread等方法,回到主线程并获取调用栈。不用说也能猜到这种想法并不可行,否则就没有写作本文的必要了。
这篇文章的重点不是介绍获取调用栈的细节,而是在实现过程中的遇到的诸多问题和尝试过的解决方案。有的方案也许不能解决问题,但在思考的过程中能够把知识点串联起来,在我看来这才是本文最大的价值。
在介绍后续知识之前,有必要介绍一下调用栈的相关背景知识。
调用栈
首先聊聊栈,它是每个线程独享的一种数据结构。借用维基百科上的一张图片:上图表示了一个栈,它分为若干栈帧(frame),每个栈帧对应一个函数调用,比如蓝色的部分是
DrawSquare函数的栈帧,它在执行的过程中调用了
DrawLine函数,栈帧用绿色表示。
可以看到栈帧由三部分组成:函数参数,返回地址,帧内的变量。举个例子,在调用
DrawLine函数时首先把函数的参数入栈,这是第一部分;随后将返回地址入栈,这表示当前函数执行完后回到哪里继续执行;在函数内部定义的变量则属于第三部分。
Stack Pointer(栈指针)表示当前栈的顶部,由于大部分操作系统的栈向下生长,它其实是栈地址的最小值。根据之前的解释,Frame Pointer 指向的地址中,存储了上一次 Stack Pointer 的值,也就是返回地址。
在大多数操作系统中,每个栈帧还保存了上一个栈帧的 Frame Pointer,因此只要知道当前栈帧的 Stack Pointer 和 Frame Pointer,就能知道上一个栈帧的 Stack Pointer 和 Frame Pointer,从而递归的获取栈底的帧。
显然当一个函数调用结束时,它的栈帧就不存在了。
因此,调用栈其实是栈的一种抽象概念,它表示了方法之间的调用关系,一般来说从栈中可以解析出调用栈。
失败的传统方法
最初的想法很简单,既然callstackSymbols只能获取当前线程的调用栈,那在目标线程调用就可以了。比如
dispatch_async到主队列,或者
performSelector系列,更不用说还可以用 Block 或者代理等方法。
我们以
UIViewController的
viewDidLoad方法为例,推测它底层都发生了什么。
首先主线程也是线程,就得按照线程基本法来办事。线程基本法说的是首先要把线程运行起来,然后(如果有必要,比如主线程)启动 runloop 进行保活。我们知道 runloop 的本质就是一个死循环,在循环中调用多个函数,分别判断 source0、source1、timer、dispatch_queue 等事件源有没有要处理的内容。
和 UI 相关的事件都是 source0,因此会执行
__CFRunLoopDoSources0,最终一步步走到
viewDidLoad。当事件处理完后 runloop 进入休眠状态。
假设我们使用
dispatch_async,它会唤醒 runloop 并处理事件,但此时
__CFRunLoopDoSources0已经执行完毕,不可能获取到
viewDidLoad的调用栈。
performSelector系列方法的底层也依赖于 runloop,因此它只是像当前的 runloop 提交了一个任务,但是依然要等待现有任务完成以后才能执行,所以拿不到实时的调用栈。
总而言之,一切涉及到 runloop,或者需要等待
viewDidLoad执行完的方案都不可能成功。
信号
要想不依赖于viewDidLoad完成,并在主线程执行代码,只能从操作系统层面入手。我尝试了使用信号(Signal)来实现,
信号其实是一种软中断,也是由系统的中断处理程序负责处理。在处理信号时,操作系统会保存正在执行的上下文,比如寄存器的值,当前指令等,然后处理信号,处理完成后再恢复执行上下文。
因此从理论上来说,信号可以强制让目标线程停下,处理信号再恢复。一般情况下发送信号是针对整个进程的,任何线程都可以接受并处理,也可以用
pthread_kill()向指定线程发送某个信号。
信号的处理可以用
signal或者
sigaction来实现,前者比较简单,后者功能更加强大。
比如我们运行程序后按下
Ctrl + C实际上就是发出了
SIGINT信号,以下代码可以在按下
Ctrl + C时做一些输出并避免程序退出:
void sig_handler(int signum) { printf("Received signal %d\n", signum); } void main() { signal(SIGINT, sig_handler); }
遗憾的是,使用
pthread_kill()发出的信号似乎无法被上述方法正确处理,查阅各种资料无果后放弃此思路。但至今任然觉得这是可行的,如果有人知道还望指正。
Mach_thread
回忆之前对栈的介绍,只要知道 StackPointer 和 FramePointer 就可以完全确定一个栈的信息,那有没有办法拿到所有线程的 StackPointer 和 FramePointer 呢?答案是肯定的,首先系统提供了
task_threads方法,可以获取到所有的线程,注意这里的线程是最底层的 mach 线程,它和 NSThread 的关系稍后会详细阐述。
对于每一个线程,可以用
thread_get_state方法获取它的所有信息,信息填充在
_STRUCT_MCONTEXT类型的参数中。这个方法中有两个参数随着 CPU 架构的不同而改变,因此我定义了
BS_THREAD_STATE_COUNT和
BS_THREAD_STATE这两个宏用于屏蔽不同 CPU 之间的区别。
在
_STRUCT_MCONTEXT类型的结构体中,存储了当前线程的 Stack Pointer 和最顶部栈帧的 Frame Pointer,从而获取到了整个线程的调用栈。
在项目中,调用栈存储在
backtraceBuffer数组中,其中每一个指针对应了一个栈帧,每个栈帧又对应一个函数调用,并且每个函数都有自己的符号名。
接下来的任务就是根据栈帧的 Frame Pointer 获取到这个函数调用的符号名。
符号解析
就像 “把大象关进冰箱需要几步” 一样,获取 Frame Pointer 对应的符号名也可以分为以下几步:根据 Frame Pointer 找到函数调用的地址
找到 Frame Pointer 属于哪个镜像文件
找到镜像文件的符号表
在符号表中找到函数调用地址对应的符号名
这实际上都是 C 语言编程问题,我没有相关经验,不过好在有前人的研究成果可以借鉴。感兴趣的读者可以直接阅读源码。
揭秘 NSThread
根据上述分析,我们可以获取到所有线程以及他们的调用堆栈,但如果想单独获取某个线程的堆栈呢?问题在于,如何建立 NSThread 线程和内核线程之间的联系。再次 Google 无果后,我找到了 GNUStep-base 的源码,下载了 1.24.9 版本,其中包含了 Foundation 库的源码,我不能确保现在的 NSThread 完全采用这里的实现,但至少可以从
NSThread.m类中挖掘出很多有用信息。
NSThread 的封装层级
很多文章都提到了 NSThread 是 pthread 的封装,这就涉及两个问题:pthread 是什么
NSThread 如何封装 pthread
pthread 中的字母 p 是 POSIX 的简写,POSIX 表示 “可移植操作系统接口(Portable Operating System Interface)”。
每个操作系统都有自己的线程模型,不同操作系统提供的,操作线程的 API 也不一样,这就给跨平台的线程管理带来了问题,而 POSIX 的目的就是提供抽象的 pthread 以及相关 API,这些 API 在不同操作系统中有不同的实现,但是完成的功能一致。
Unix 系统提供的
thread_get_state和
task_threads等方法,操作的都是内核线程,每个内核线程由
thread_t类型的 id 来唯一标识,pthread 的唯一标识是
pthread_t类型。
内核线程和 pthread 的转换(也即是
thread_t和
pthread_t互转)很容易,因为 pthread 诞生的目的就是为了抽象内核线程。
说 NSThread 封装了 pthread 并不是很准确,NSThread 内部只有很少的地方用到了 pthread。NSThread 的
start方法简化版实现如下:
- (void) start { pthread_attr_t attr; pthread_t thr; errno = 0; pthread_attr_init(&attr); if (pthread_create(&thr, &attr, nsthreadLauncher, self)) { // Error Handling } }
甚至于 NSThread 都没有存储新建 pthread 的
pthread_t标识。
另一处用到 pthread 的地方就是 NSThread 在退出时,调用了
pthread_exit()。除此以外就很少感受到 pthread 的存在感了,因此个人认为 “NSThread 是对 pthread 的封装” 这种说法并不准确。
PerformSelectorOn
实际上所有的performSelector系列最终都会走到下面这个全能函数:
- (void) performSelector: (SEL)aSelector onThread: (NSThread*)aThread withObject: (id)anObject waitUntilDone: (BOOL)aFlag modes: (NSArray*)anArray;
而它仅仅是一个封装,根据线程获取到 runloop,真正调用的还是 NSRunloop 的方法:
- (void) performSelector: (SEL)aSelector target: (id)target argument: (id)argument order: (NSUInteger)order modes: (NSArray*)modes{}
这些信息将组成一个
Performer对象放进 runloop 等待执行。
NSThread 转内核 thread
由于系统没有提供相应的转换方法,而且 NSThread 没有保留线程的pthread_t,所以常规手段无法满足需求。
一种思路是利用
performSelector方法在指定线程执行代码并记录
thread_t,执行代码的时机不能太晚,如果在打印调用栈时才执行就会破坏调用栈。最好的方法是在线程创建时执行,上文提到了利用
pthread_create方法创建线程,它的回调函数
nsthreadLauncher实现如下:
static void *nsthreadLauncher(void* thread) { NSThread *t = (NSThread*)thread; [nc postNotificationName: NSThreadDidStartNotification object:t userInfo: nil]; [t _setName: [t name]]; [t main]; [NSThread exit]; return NULL; }
很神奇的发现系统居然会发送一个通知,通知名不对外提供,但是可以通过监听所有通知名的方法得知它的名字:
@"_NSThreadDidStartNotification",于是我们可以监听这个通知并调用
performSelector方法。
一般 NSThread 使用
initWithTarget:Selector:object方法创建。在 main 方法中 selector 会被执行,main 方法执行结束后线程就会退出。如果想做线程保活,需要在传入的 selector 中开启 runloop,详见我的这篇文章: 深入研究 Runloop 与线程保活。
可见,这种方案并不现实,因为之前已经解释过,
performSelector依赖于 runloop 开启,而 runloop 直到
main方法才有可能开启。
回顾问题发现,我们需要的是一个联系 NSThread 对象和内核 thread 的纽带,也就是说要找到 NSThread 对象的某个唯一值,而且内核 thread 也具有这个唯一值。
观察一下 NSThread,它的唯一值只有对象地址,对象序列号(Sequence Number) 和线程名称:
<NSThread: 0x144d095e0>{number = 1, name = main}
地址分配在堆上,没有使用意义,序列号的计算没有看懂,因此只剩下 name。幸运的是 pthread 也提供了一个方法
pthread_getname_np来获取线程的名字,两者是一致的,感兴趣的读者可以自行阅读
setName方法的实现,它调用的就是 pthread 提供的接口。
这里的 np 表示 not POSIX,也就是说它并不能跨平台使用。
于是解决方案就很简单了,对于 NSThread 参数,把它的名字改为某个随机数(我选择了时间戳),然后遍历 pthread 并检查有没有匹配的名字。查找完成后把参数的名字恢复即可。
主线程转内核 thread
本来以为问题已经圆满解决,不料还有一个坑,主线程设置 name 后无法用pthread_getname_np读取到。
好在我们还可以迂回解决问题: 事先获得主线程的
thread_t,然后进行比对。
上述方案要求我们在主线程中执行代码从而获得
thread_t,显然最好的方案是在 load 方法里:
static mach_port_t main_thread_id; + (void)load { main_thread_id = mach_thread_self(); }
总结
以上就是 BSBacktraceLogger 的全部分析,它只有一个类,400行代码,因此还算是比较简单。然而 NSThread、NSRunloop 以及 GCD 的源码着实值得反复研究、阅读。完成一个技术项目往往最大的收获不是最后的结果,而是实现过程中的思考。这些走过的弯路加深了对知识体系的理解。
关注与订阅
搜索 “iOSZhaZha” 关注微信公众号,第一时间获得更新参考资料
Call StackKSCrash
深入理解RunLoop
iOS中线程Call Stack的捕获和解析(一)、iOS中线程Call Stack的捕获和解析(二)
相关文章推荐
- 获取任意线程调用栈的那些事
- 获取任意线程调用栈的那些事
- 获取任意线程调用栈的那些事
- 获取iOS任意线程调用堆栈(三)符号化理论:从Mach-o结构分析类名方法名
- 获取iOS任意线程调用堆栈(五)完整实现:BSBacktraceLogger
- 获取iOS任意线程调用堆栈(一)获取任意线程的调用栈地址列表
- 获取iOS任意线程调用堆栈(四)符号化实战
- 获取iOS任意线程调用堆栈(二)符号化理论:Mach-o文件结构
- 织梦Dedecms 任意页面调用获取文章 评论数 和 收藏数
- Windows下获取Dump文件以及进程下各线程调用栈的方法总结
- linux syscall系统调用获取线程PID
- 如何获取当前线程的调用堆栈
- linux syscall系统调用获取线程PID
- 如何在jsp页面调用的java类中获取当前线程的request和session
- js调用百度地图接口绘制任意多边形并获取每个点的经纬度
- Windows下获取Dump文件以及进程下各线程调用栈的方法总结
- 获取内核当前执行模块和当前发生异常地址和线程异常Handler调用步骤
- 线程相关函数(2)-pthread_self()获取调用线程ID
- 正确利用线程调用堆栈获取上级调用函数的名称
- 正确利用线程调用堆栈获取上级调用函数的名称