调试垃圾收集中的 python 个分段错误

Question

我遇到了在 cPython 中的垃圾回收期间发生的分段错误 (SIGSEGV)。我也遇到过一个进程被 SIGBUS 终止的例子。我自己的代码主要是 python 和一些非常高级的 Cython。我绝对不会 - 故意和明确地 - 使用指针或直接写入内存。

来自核心转储的示例回溯（使用 gdb 提取）：

#0  0x00007f8b0ac29471 in subtype_dealloc (self=<Task at remote 0x7f8afc0466d8>)
    at /usr/src/debug/Python-3.5.1/Objects/typeobject.c:1182
#1  0x00007f8b0abe8947 in method_dealloc (im=0x7f8afc883e08) at /usr/src/debug/Python-3.5.1/Objects/classobject.c:198
#2  0x00007f8b0ac285a9 in clear_slots (type=type@entry=0x560219f0fa88, 
    self=self@entry=<Handle at remote 0x7f8afc035948>) at /usr/src/debug/Python-3.5.1/Objects/typeobject.c:1044
#3  0x00007f8b0ac29506 in subtype_dealloc (self=<Handle at remote 0x7f8afc035948>)
    at /usr/src/debug/Python-3.5.1/Objects/typeobject.c:1200
#4  0x00007f8b0ac8caad in PyEval_EvalFrameEx (
    f=f@entry=Frame 0x56021a01ff08, for file /usr/lib64/python3.5/asyncio/base_events.py, line 1239, in _run_once (self=<_UnixSelectorEventLoop(_coroutine_wrapper_set=False, _current_handle=None, _ready=<collections.deque at remote 0x7f8afd39a250>, _closed=False, _task_factory=None, _selector=<EpollSelector(_map=<_SelectorMapping(_selector=<...>) at remote 0x7f8afc868748>, _epoll=<select.epoll at remote 0x7f8b0b1b8e58>, _fd_to_key={4: <SelectorKey at remote 0x7f8afcac8a98>, 6: <SelectorKey at remote 0x7f8afcac8e08>, 7: <SelectorKey at remote 0x7f8afcac8e60>, 8: <SelectorKey at remote 0x7f8afc873048>, 9: <SelectorKey at remote 0x7f8afc873830>, 10: <SelectorKey at remote 0x7f8afc873af0>, 11: <SelectorKey at remote 0x7f8afc87b620>, 12: <SelectorKey at remote 0x7f8afc87b7d8>, 13: <SelectorKey at remote 0x7f8afc889af0>, 14: <SelectorKey at remote 0x7f8afc884678>, 15: <SelectorKey at remote 0x7f8afc025eb8>, 16: <SelectorKey at remote 0x7f8afc889db0>, 17: <SelectorKey at remote 0x7f8afc01a258>, 18: <SelectorKey at remote 0x7f8afc...(truncated), 
    throwflag=throwflag@entry=0) at /usr/src/debug/Python-3.5.1/Python/ceval.c:1414

扫荡期间（我认为）：

#1  0x00007f0a0624c63f in visit_decref (op=, data=<optimized out>)
    at /usr/src/debug/Python-3.5.1/Modules/gcmodule.c:373
#2  0x00007f0a0624b813 in subtract_refs (containers=<optimized out>)
    at /usr/src/debug/Python-3.5.1/Modules/gcmodule.c:398
#3  collect (generation=generation@entry=2, n_collected=n_collected@entry=0x7f09d75708c8, 
    n_uncollectable=n_uncollectable@entry=0x7f09d75708d0, nofail=nofail@entry=0)
    at /usr/src/debug/Python-3.5.1/Modules/gcmodule.c:951

并且在 malloc 期间也有一次：

#0  _PyObject_Malloc (ctx=0x0, nbytes=56) at /usr/src/debug/Python-3.4.3/Objects/obmalloc.c:1159
1159                if ((pool->freeblock = *(block **)bp) != NULL) {
(gdb) bt
#0  _PyObject_Malloc (ctx=0x0, nbytes=56) at /usr/src/debug/Python-3.4.3/Objects/obmalloc.c:1159

和 SIGBUS 跟踪（看起来它发生在 cPython 从另一个错误中恢复时）：

#0  malloc_printerr (ar_ptr=0x100101f0100101a, ptr=0x7f067955da60 <generations+32>, str=0x7f06785a2b8c "free(): invalid size", action=3) at malloc.c:5009
5009        set_arena_corrupt (ar_ptr);
(gdb) bt
#0  malloc_printerr (ar_ptr=0x100101f0100101a, ptr=0x7f067955da60 <generations+32>, str=0x7f06785a2b8c "free(): invalid size", action=3) at malloc.c:5009
#1  _int_free (av=0x100101f0100101a, p=<optimized out>, have_lock=0) at malloc.c:3842
Python Exception <type 'exceptions.RuntimeError'> Type does not have a target.:

这些回溯来自带有 Python 3.5.1 的 Fedora 24，一些来自带有 Python 3.4.3 的 Centos 7。所以我排除了以下问题：

内存不足（可能是，但巧合的是，我的笔记本电脑和（虚拟）服务器出现了同样的问题，并且显示没有其他工作正常）。
OS 或 cPython 或其组合中的问题。

所以 - 像往常一样 - 它一定是我自己的代码中的东西。它是用于某些（计算）'tasks' 并发的线程代码和一个异步循环的线程运行的混合体。代码库还有其他 'workloads'，运行很好。 'serving' 这个 'workload' 的代码差异对我来说很突出，我使用 (threading.RLock) 锁来序列化一些请求，我正在序列化并写入磁盘.

如有任何关于如何找到根本原因的建议，我们将不胜感激！

我尝试过的事情：

将使用的外部依赖项剥离到最低限度（即 cloudpickle）：没有区别
在显式收集之前和之后转储垃圾收集器看到的所有对象类型的计数，并查看是否有在崩溃之前跟踪的对象类型并且不在 'successful' 垃圾收集中：有不是。
使用 GDB 通过核心转储：关于 C 和 Python 回溯并不完全一致。
运行 MALLOC_CHECK_=2：除了进程已退出且退出代码为 -11 之外，我没有看到任何错误消息。

编辑 1

得到了一些东西：https://gist.github.com/frensjan/dc9bc784229fec844403c9d9528ada66

最值得注意的是：

==19072== Invalid write of size 8
==19072==    at 0x47A3B7: subtype_dealloc (typeobject.c:1157)
==19072==    by 0x4E0696: PyEval_EvalFrameEx (ceval.c:1388)
==19072==    by 0x58917B: gen_send_ex (genobject.c:104)
==19072==    by 0x58917B: _PyGen_Send (genobject.c:158)
...
==19072==    by 0x4E2A6A: call_function (ceval.c:4262)
==19072==    by 0x4E2A6A: PyEval_EvalFrameEx (ceval.c:2838)
==19072==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

和

==19072== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==19072==  Access not within mapped region at address 0x8
==19072==    at 0x47A3B7: subtype_dealloc (typeobject.c:1157)
==19072==    by 0x4E0696: PyEval_EvalFrameEx (ceval.c:1388)
==19072==    by 0x58917B: gen_send_ex (genobject.c:104)
==19072==    by 0x58917B: _PyGen_Send (genobject.c:158)

但是 valgrind 发现的错误指向与我之前得到的核心转储相同的位置，离我的代码不远……不太确定如何处理这个。

环境：Python 3.4.5+ 在 Centos 7 上使用 ./configure --without-pymalloc 构建。运行 python 使用 valgrind --tool=memcheck --dsymutil=yes --track-origins=yes --show-leak-kinds=all --trace-children=yes python ...

非常感谢任何帮助！

Answer 1

我相当确信我运行遇到的问题是由于 issue 26617 in CPython which is fixed in 7bfa6f2。

我已经通过在 7bfa6f2 之前 提交的构建重现问题（运行到 SIGSEGV）并且无法重现它来检查这一点构建提交 7bfa6f2.

调试垃圾收集中的 python 个分段错误

Debugging python segmentation faults in garbage collection

python

c

multithreading

garbage-collection

memory-corruption

编辑 1