Facebook调试iOS文件损坏的过程

Facebook工程师Slobodan Predolac和Nicolas Spielberg最近描述了他们如何解决了一个顽固的移动调试问题，并且使崩溃频率降低了50%以上。在此过程中，他们展示了若干通用的技巧以及Facebook发开的工具，这些对不断快速增长的大型代码库会有所帮助。

\\

Predolac和Spielberg回顾说，此bug开始的时候有点像Core Data崩溃。他们首先使用Facebook自己的工具Hipal和Scuba从崩溃日志中查找和搜集数据，分析的结果是Core Data错误编码没有统一的规律。

\\

在查找问题的根源时，Facebook开发软件的方式是阻碍此过程的障碍之一，因为Facebook以月为发布周期，而且有数百名开发人员向各发布版本提交代码。所以，这两位工程师在文中描述说，“即使我们能够缩小引入bug的时间范围，也无法隔离数千次代码提交来纠错”。况且每次的版本发布都经过A/B测试，这就更难区分“到底是代码还是配置导致了该问题”。

\\

证明以上方式行不通后，Facebook的工程师开始做出不同的假设，在排除了若干假设后，他们试着验证下一个假设，那就是Core Data是该问题的根本原因所在。于是他们找到了“一段受影响的代码，他们可以很容易地将这块代码从Core Data切换为SQLite，用以验证他们的假设”。

\\

之后没多久，他们就收到崩溃报告，报告指出某文件被“可恶的线程或进程”重写了。这说明查找问题的方向是正确的，但是在“庞大的代码库中”顺利找到此线程或进程看起来不是一件容易的事情。他们采取的方法是在打开SQLite文件之前打开一个诱饵文件，这样就能捕捉到进行写文件操作的线程，然后查看损坏的文件。通过此方法，他们在所有的附件中发现了一个相同的前缀：17 03 03 00 28，然后使用lldb中的以下命令设置了一个断点，用以查找试图向POSIX write()方法发送此内容的任意线程：

\\

\breakpoint set -n write -c \"(*(char**) ($esp + 8))[0]==0x17 \    \u0026amp;\u0026amp; (*(char**) ($esp + 8))[1]==0x03 \    \u0026amp;\u0026amp; (*(char**) ($esp + 8))[2]==0x03 \    \u0026amp;\u0026amp; (*(char**) ($esp + 8))[3]==0x00\    \u0026amp;\u0026amp; (*(char**) ($esp + 8))[4]==0x28\"\

\\

很快他们发现SPDY协议栈很可能就是罪魁祸首，接下来就验证该假设。他们使用Fishhook完成了验证的工作，这是Facebook开发的一款开源工具，它可以替换系统的write调用。

\\

\// setup a honeypot file\int trap_fd = open(…);\// Create new function to detect writes to the honeypot\static WRITE_FUNC_T original_write = dlsym(RTLD_DEFAULT, \"write\");\ssize_t corruption_write(int fd, const void *buf, size_t size) {\FBFatal(fd != trap_fd, @\"Writing to the honeypot file\");\return original_write(fd, buf, size);\}\\// Replace the system write with our “checked version”\rebind_symbols((struct rebinding[1]){{(char *)\"write\