未显式调用gc.disable()时Python gc被意外禁用的原因及排查问询

可能的根因 #

• C扩展/第三方组件异常调用：Python层的gc.disable()和C层面的PyGC_Disable()调用都会关闭全局GC，你业务代码没有显式调用，大概率是引入的C扩展、APM监控探针、数据库驱动等组件的bug导致：比如部分老版本的性能监控C扩展会为了降低开销临时关闭GC，异常分支漏写配对的PyGC_Enable()逻辑；仅单台出现大概率是该机器的组件版本和其他机器不一致，或者部署了其他机器没有的注入类组件。
• Python 2.7.5 版本已知bug：你使用的2.7.5是2013年的老旧版本，存在多个GC相关的已知问题：比如GC回调函数抛出未捕获异常时会直接禁用GC；父进程处于GC执行阶段时fork子进程，子进程的GC状态会被异常置为禁用；如果该机器的业务请求命中了其他机器没有触发的冷路径逻辑（比如临时fork子进程、触发GC回调异常），就会出现单台异常。
• 人为操作/临时调试遗留：如果该机器曾有人登录调试进程，通过gdb注入代码、或者attach进程调试时调用了gc.disable()，没有手动恢复GC状态也会导致该问题。

排查路径 #

• 优先排查环境差异：对比异常机器和正常机器的环境：
  • 执行pip freeze对比所有Python依赖包的版本，重点关注C实现的扩展包（比如gevent、mysqlclient、监控探针类包）的版本差异
  • 检查系统级注入组件，比如是否部署了APM探针、安全审计组件，对比配置和版本是否和其他机器一致
• 直接抓取GC禁用的调用栈：对仍在运行的异常进程，用gdb给PyGC_Disable函数下断点，只要有调用就会触发断点打印完整调用栈，直接定位调用方：

  gdb -p $pid
  (gdb) break PyGC_Disable
  (gdb) continue
  

  触发断点后执行bt打印调用栈，就能直接知道是哪个组件或者哪段代码调用了GC禁用逻辑。
• 检查GC自定义逻辑：注入代码打印gc.callbacks列表，检查是否注册了自定义的GC回调函数，手动执行这些回调验证是否会抛出未捕获异常，排查回调异常导致的GC自动禁用。
• 排查操作历史：查看该机器的bash历史、/var/log/secure等日志，确认是否有人员登录调试的记录，排除人为操作遗留的问题。

内容的提问来源于stack exchange，提问作者Eric Lin