Py_Finalize() 会导致 Python 3.9 出现分段错误，但不会导致 Python 2.7

我正在开发一个使用 C++ matplotlib 包装器的项目matplotlibcpp.h https://github.com/lava/matplotlib-cpp.

使用这个原始头文件的最小示例是

    #include "matplotlibcpp.h"

    namespace plt = matplotlibcpp;

    int main() {
        plt::plot({1,3,2,4});
        plt::show();
    }

注意：似乎分段错误并不依赖于上面的示例，而是真正出现在任何调用该函数中的函数的程序中。mathplotlibcpp.h头文件。我选择这个绘图示例是因为实际绘图将起作用，您将看到绘图，但一旦关闭它并且程序完成，您将得到分段错误。此外，它是项目 github 页面上的官方示例之一。

您还可以将主函数中的两行替换为例如plt::figure()你仍然会得到一个工作程序和一个分段错误在执行的最后.

用python2.7编译它似乎工作正常

g++ minimal.cpp -std=c++11 -I/usr/include/python2.7 -I/home/<user>/.local/lib/python2.7/site-packages/numpy/core/include/ -lpython2.7

$ ldd a.out 
    linux-vdso.so.1 (0x00007ffe1f3f7000)
    libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0x00007f8320f8f000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f8320db2000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f8320c6d000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f8320c53000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f8320a86000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f8320a65000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f8320a5c000)
    libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f8320a57000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f83211c2000)

用python3.9编译它似乎会导致分段错误

g++ minimal.cpp -std=c++11 -I/usr/include/python3.9 -I/home/pascal/.local/lib/python3.9/site-packages/numpy/core/include/ -lpython3.9

here ./a.out结果是分段错误（核心转储）

$ ldd a.out 
    linux-vdso.so.1 (0x00007fff8dbc5000)
    libpython3.9.so.1.0 => /usr/lib/libpython3.9.so.1.0 (0x00007f60176ec000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f601750f000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f60173ca000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f60173b0000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f60171e3000)
    libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f60171c2000)
    libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f60171b9000)
    libutil.so.1 => /usr/lib/libutil.so.1 (0x00007f60171b4000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6017adf000)

两者都是在使用 arch linux 和 g++ 版本 10.2.0 的系统上编译的。

这是一issue https://github.com/lava/matplotlib-cpp/issues/248在他们的 git 中找到了，但到目前为止，没有人想出解决方案。

现在我将问题隔离为调用Py_Finalize()。对于Python3，这调用Py_FinalizeEx()。所以Python2和Python3之间是有区别的。

现在在matplotlibcpp.h file Py_Finalize()在解构函数中调用：

~_interpreter() {
    Py_Finalize();
}

如果您将其注释掉，您就可以消除分段错误。现在我真的对这个终结函数感到困惑，因为文档状态（对于 python3）

错误和警告：模块和模块中对象的破坏是 以随机顺序完成；这可能会导致析构函数（del（） 方法） 当它们依赖于其他对象（甚至函数）或模块时会失败。 Python 加载的动态加载的扩展模块不是 卸载。 Python解释器分配的少量内存 可能无法释放（如果您发现泄漏，请报告）。内存绑定 对象之间的循环引用没有被释放。一些记忆 由扩展模块分配的空间可能无法释放。一些扩展可能 如果调用它们的初始化例程超过 一次;如果应用程序调用 Py_Initialize() 并且 Py_FinalizeEx() 多次。

现在还有一个Kill()头文件中的函数显式调用解构函数，但从未使用过。

现在，似乎只有当我们超出范围时才会调用解构函数，即它们从不使用free() or delete。我认为它只是尝试释放已经释放的东西，但弄清楚它有点困难，因为我对 C Python API 非常不熟悉。

堆栈跟踪：（我希望我正确安装了 python 调试符号。不知道为什么 Qt5 小部件符号不显示。）

注意：我编译了下面的堆栈跟踪-std=c++17 -Wall -g

另请注意该函数matplotlibcpp::detail::_interpreter::interkeeper(bool)显式调用解构函数，请参阅kill()。我提到这一点是因为下面的堆栈跟踪中提到了这个函数 - 但我不确定为什么。该函数的源代码有以下注释：

/* 
    For now, _interpreter is implemented as a singleton since its currently not possible to have
   multiple independent embedded python interpreters without patching the python source code
   or starting a separate process for each. [1]
   Furthermore, many python objects expect that they are destructed in the same thread as they
   were constructed. [2] So for advanced usage, a `kill()` function is provided so that library
   users can manually ensure that the interpreter is constructed and destroyed within the
   same thread.
     1: http://bytes.com/topic/python/answers/793370-multiple-independent-python-interpreters-c-c-program
     2: https://github.com/lava/matplotlib-cpp/pull/202#issue-436220256
   */

堆栈跟踪：

Thread 1 "MAIN" received signal SIGSEGV, Segmentation fault.
0x00007fffde884225 in ?? () from /usr/lib/libQt5Widgets.so.5
(gdb) bt
#0  0x00007fffde884225 in ?? () from /usr/lib/libQt5Widgets.so.5
#1  0x00007fffdf14540a in ?? () from /usr/lib/python3.9/site-packages/PyQt5/QtWidgets.abi3.so
#2  0x00007fffe2bc67eb in ?? () from /usr/lib/python3.9/site-packages/PyQt5/QtCore.abi3.so
#3  0x00007ffff7d0ea5c in cfunction_vectorcall_NOARGS (func=0x7fffe2cccb80, args=<optimized out>, nargsf=<optimized out>, kwnames=<optimized out>) at Objects/methodobject.c:485
#4  0x00007ffff7e0ca69 in atexit_callfuncs (module=<optimized out>) at ./Modules/atexitmodule.c:93
#5  0x00007ffff7c744e7 in call_py_exitfuncs (tstate=0x555555597240) at Python/pylifecycle.c:2374
#6  0x00007ffff7dfc627 in Py_FinalizeEx () at Python/pylifecycle.c:1373
#7  0x000055555555926d in matplotlibcpp::detail::_interpreter::~_interpreter (this=0x55555555e620 <matplotlibcpp::detail::_interpreter::interkeeper(bool)::ctx>, 
    __in_chrg=<optimized out>) at /home/pascal/test/cpp/foo/matplotlibcpp.h:288
#8  0x00007ffff76d24a7 in __run_exit_handlers () from /usr/lib/libc.so.6
#9  0x00007ffff76d264e in exit () from /usr/lib/libc.so.6
#10 0x00007ffff76bab2c in __libc_start_main () from /usr/lib/libc.so.6
#11 0x000055555555646e in _start ()

我无法轻松访问 Linux 来测试它，但我想我现在明白发生了什么。

1. matplotlibcpp使用静态变量来保存Python解释器（参见里面的第129行interkeeper(bool should_kill)）。与 C++ 静态函数变量一样，它在第一次调用函数时初始化，并在程序退出时销毁（参考 https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables).

2. When main完成，libc为所有共享库和您的程序运行清理例程（即__run_exit_handlers在堆栈跟踪中）。由于您的程序是 C++ 程序，因此其退出处理程序的一部分会破坏所有使用的静态变量。其中之一是Python解释器。它的析构函数调用Py_Finalize()这是Python 的清理例程。到现在为止，一切都很好。

3. Python也有类似的atexit允许来自任何地方的 Python 代码注册在解释器关闭期间应调用的函数的机制。显然，这里选择使用的后端 matplotlib 是 PyQt5。它似乎注册了这样的 atexit 回调。

4. PyQt5 的回调被调用并崩溃。请注意，现在这是内部 PyQt5 代码。为什么会崩溃？我的“有根据的”猜测是 Qt 的library退出处理程序是已经打电话了在步骤 2 中，在调用程序的退出处理程序之前。这显然会导致库中出现一些奇怪的状态（也许某些对象被释放？）并崩溃。

这留下了两个有趣的问题：

1. 如何解决这个问题？解决方案应该是破坏ctx在程序退出之前，因此 Python 解释器会在任何共享库自行终止之前被破坏。众所周知，静态寿命会导致类似的问题 https://en.cppreference.com/w/cpp/language/siof。如果更改 matplotlibcpp 的接口不使用全局静态不是一个可能的解决方案，我认为你真的必须手动调用plt::detail::_interpreter::kill()在主要功能的末尾。你应该能够使用atexit() https://en.cppreference.com/w/cpp/utility/program/atexit并注册一个回调，在库拆卸之前杀死解释器 - 但我还没有测试过它。

2. 为什么这会起作用？我的猜测是，也许 PyQt5 回调中的某些内容发生了变化，导致了这次崩溃，或者您在 Python 2 中使用了不同的后端。如果在程序退出之前没有其他库破坏性地终止，那就没问题。