lldb调试使用python脚本问题总结

lldb调试器可以使用python脚本实现功能增强，但也不是可以随心所欲的，在实际中有很多地方需要注意。

首先是对多线程环境调试使用python脚本，也要考虑python脚本有多线程安全，尤其是有许多任务繁重的工作线程，目标函数许多线程同时在使用时，脚本用到的全局变量就成了临界资源。如果只是通常地是使用python实现增强调试指令，手工指令显示结果，调试器运行在交互状态，就不会想到使用python脚本也会多线程运行。但是在做断点catch调试时，脚本自动在各catch点触发的线程上运行，没错python脚本运行在多线程环境了。python脚本用锁后，就要注意一个问题，锁住的代码块要考虑脚本异常后，因为锁没有释放使其它线程在catch点上饿死，影响了程序的运行，当然设计的调试自然就失败（不工作，达不到目的）了。

第二，也是与catch调试情况相关的，就是要注意调试时调用了程序的函数与catch点之间是否存在依赖关系。如果存在依赖关系，catch点触发的函数调用又使用了catch点的代码，结果就是catch点递归触发，或者说这里链环。通常调试器会在这种情况输出警告提示，"warning:hit point ..., skip the command..."，就是调试器尝试跳过catch点定下的操作，但是并不是总能有效。最后结果只有一个，主线程被异常事件唤醒停在mach_msg_trap，也就是程序挂了。lldb比gdb在p指令多了一个打印对象的功能，这个功能并非由调试器实现的，而是调用了oc对象的description函数，和NSLog打印oc对象一样，调用了被打印的oc对象的函数。如果想在catch点，通过以上两种方法获取oc对象的打印信息，这就要考虑以上两种方法所依赖的函数或机制流程了。举例，在_pthread*的函数集合，catch触发操作打印一个oc字符串（po @"abc" 或 p (void)NSLog(@"abc")），调试继续，悲剧随即发生，程序挂了。因为触发的catch操作依赖了_pthread*的函数。跟着了catch触发操作引起的流程循环，如果你想在CFRunLoop里面的各步骤中，使用以上两种打印对象信息的方法，就要当心会不会引起了某个CFRunLoop的事件，又使得CFRunLoop因此又运行在你的catch点上。我尝试在RunLoop的observer点的回调函数catch打印info的信息，结果程序运行就挂了。没错，你发现了，本篇写的就是我踩过的坑。

第三，就是不要在python脚本中，通过HandleCommand执行调试器指令来读取寄存器，不要指望能正确读出中断现场的寄存器的值。因为python脚本运行在lldb之上，现在又由python调用lldb的命令（或指令），所以在这样的情景下，lldb读寄存器命令与程序中断（或断点）现场就相隔着一层python，lldb调试命令很自然就不是在读取程序断点的现场。因此在python脚本就必须使用lldb.frame.register来读取读取程序断点的现场，因为这是python的lldb模块对lldb调试器保存的寄存器现场进行了keep one copy。