如何深入 Python 虚拟机追查 HTTP 服务 core dump 导致 502 的问题

作者 | 今日头条技术团队

概述

今日头条目前大部分 Python 的 HTTP 服务都是用 uWSGI 托管 Python 多进程的 Django 或者 Flask 框架的 App。而多进程模型就会有进程间通信的问题，对此 uWSGI 提供了 spooler 功能用于让不同 worker 进程把数据通过共享内存传给单独进程以集中进行处理的功能。但是 uWSGI 的 Python C 扩展实现有 bug，对 Python tuple 对象的引用计数处理是错误的，会在多线程环境下有小概率导致进程崩溃，从而造成线上 HTTP 请求返回 502 错误。

经过几天的分析排查和复现，最终修复了导致对象引用计数出错的代码。整个过程涉及到 uWSGI 和 Python 虚拟机中内置类型的实现、对象引用计数和对象池、GC、多线程 GIL、内存管理及 GDB 使用等。本文记录了主要的排查过程，并在涉及到虚拟机实现的地方介绍对应的细节。

uWSGI 和 Python 并发模型

首先简单介绍一下 Python 与其它语言在并发处理上的不同。熟悉 Python 的同学知道，Python 2.x 的官方实现版本是有一个 GIL 的，即全局解释锁。在 Python 代码执行的大部分时间里，线程都会持有这个锁，这样不能简单通过开多线程的方式充分利用多核的优势。有人尝试把 GIL 改成更细粒度的锁，但是发现在单线程场景下运行效率有明显下降。

为了解决 Python 并发的问题，有人实现了其它方案，比如 gevent，tornado 等，不过用起来多少都有些别扭，或者容易掉坑里。

所以对于 Python 2 建议的用法是多进程模型。小计算量的 IO 操作可以开在另外一个线程里边。

而多进程模型就需要在进程管理上做一些处理。整体上来说 uWSGI 是一个宿主，用来承载其它服务。uWSGI 会先启动一个 master 进程，然后再启动各个 worker 进程和单独的 spooler 进程，并监控这些进程的运行状态。不过通常我们主要用 uWSGI 作为 Web Server，管理 Python 写的 Web Application。而不会使用 uWSGI 的 LB 之类的功能。

而由 uWSGI 管理多进程，同时进程内有不止一个线程的情况下，由于 C 扩展部分的实现有 bug，会导致 uWSGI 进程有小概率在请求处理过程中崩溃。

初步查看

少量 uWSGI 日志

线上报 502 之后，先查看 uWSGI 日志，发现会有少量 worker 崩溃的情况。平时业务出现问题，一般是 Python 层面逻辑不对，比如出现 Exception，请求超时之类的，比较少有进程直接挂掉的情况。而且我印象里 RPC Server 不太会有这种崩溃的情况，以前简单看过一眼 uWSGI 的 C 扩展部分，不过没有看细节，当时就觉得这些对对象引用计数的处理部分挺容易出错的，其它逻辑倒还好。所以我的第一直觉是 C 扩展部分写的有问题，而且很可能是 Python 对象引用计数错误导致的。

而具体到 log 能直接看到的内容并不多，大概是这样几行：

这里除了能知道是 master 进程发现 worker 进程挂了，然后又拉起来一个，其它重要信息就是 signal 11 和 signal 6 了。

一般来说出现 Segmentation Fault（signal 11）这种情况是比较麻烦的，出事的地方往往不是第一现场，有可能是另外的代码已经把内存状态跑错了。

而 Abort（signal 6）就好一点了，可能是程序主动为之。而且 GC object already tracked 这条信息非常关键，应该是 Python 虚拟机发现状态异常主动抛出来的。

于是翻出 Python 源码：

从这个宏中可以看出来，是在向 Python 虚拟机申请一个对象的时候，发现其引用计数不是 PyGCREFS_UNTRACKED。

直觉

GC_TRACK 这个宏是把对象加入 GC 链里边，是申请对象的时候的操作。看起来似乎不是减少引用计数释放内存的时候出现的问题啊。

其实也不一定，因为既然需要在使用前对对象进行 check，那大概说明这个对象的类在内部实现是有对象池的（之前只看了 int 对象池细节，但是知道很多内置类型