c++ - 调试从 C++ 调用的 Cython 代码中的崩溃

Question

我正在研究 Opencog 开源框架的 Python 绑定(bind)，试图修复一些崩溃，但我遇到了崩溃:

PyObject * pyAtomSpace;

if (atomspace)
    pyAtomSpace = py_atomspace(atomspace);

来自:

https://github.com/opencog/opencog/blob/master/opencog/cython/PythonEval.cc#L148

它在调用 cython 例程的最后一行崩溃，该例程使用带有以下 cython 代码的 python 对象包装 C++ 对象:

cdef api object py_atomspace(cAtomSpace *c_atomspace) with gil:
    cdef AtomSpace atomspace = AtomSpace_factory(c_atomspace)
    return atomspace

来自: https://github.com/opencog/opencog/blob/master/opencog/cython/opencog/atomspace_details.pyx#L407-410

崩溃是 SIGSEGV:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff6354b6f in opencog::PythonEval::getPyAtomspace (
    this=<optimized out>, atomspace=<optimized out>)
    at /home/opencog/src/opencog/opencog/cython/PythonEval.cc:160
#2  0x00007ffff6354dd7 in opencog::PythonEval::init (this=0x67eb60)
    at /home/opencog/src/opencog/opencog/cython/PythonEval.cc:103
#3  0x00007ffff635512e in opencog::PythonEval::instance (atomspace=0x62c300)
    at /home/opencog/src/opencog/opencog/cython/PythonEval.cc:226
#4  0x00007ffff7bb5a83 in opencog::CogServer::CogServer (this=0x62bd40)
    at /home/opencog/src/opencog/opencog/server/CogServer.cc:127
#5  0x00000000004141bb in TestCogServer::createInstance ()
    at /home/opencog/src/opencog/tests/cython/PythonModuleUTest.cxxtest:37
#6  0x00007ffff7bb2a4a in opencog::server (
    factoryFunction=0x4141a0 <TestCogServer::createInstance()>)
    at /home/opencog/src/opencog/opencog/server/BaseServer.cc:65
#7  0x0000000000416e51 in PythonModuleUTest::PythonModuleUTest (
    this=0x6216f0 <suite_PythonModuleUTest>)
    at /home/opencog/src/opencog/tests/cython/PythonModuleUTest.cxxtest:82

如何调试此崩溃？我尝试单步执行汇编程序。首先，我在打开 disassemble-next-line 时崩溃的行上设置了一个断点。注意:我用 routine 替换了下面的 opencog::PythonEval::getPyAtomspace(opencog::AtomSpace*):

Breakpoint 1, opencog::PythonEval::getPyAtomspace (this=0x67eb50, 
    atomspace=0x62c2f0)
    at /home/opencog/src/opencog/opencog/cython/PythonEval.cc:160
160         pyAtomSpace = py_atomspace(atomspace);
=> 0x00007ffff6354b66 <routine+6>:  48 89 f7    mov    %rsi,%rdi
   0x00007ffff6354b69 <routine+9>:  ff 15 29 69 20 00   callq  *0x206929(%rip)        # 0x7ffff655b498 <_ZL40__pyx_f_7opencog_9atomspace_py_atomspace>
   0x00007ffff6354b6f <routine+15>: 48 89 c3    mov    %rax,%rbx

callq之前的寄存器:

(gdb) info registers
rax            0x1c 28
rbx            0x67eb50 6810448
rcx            0x7ffff7716320   140737344791328
rdx            0x68 104
rsi            0x62c2f0 6472432
rdi            0x67eb50 6810448
rbp            0x7fffffffe790   0x7fffffffe790
rsp            0x7fffffffe780   0x7fffffffe780
r8             0x0  0
r9             0x9b57b0 10180528
r10            0x7fffffffe550   140737488348496
r11            0x7ffff6354b60   140737324075872
r12            0x7ffff7b8b140   140737349464384
r13            0x0  0
r14            0x62c2f0 6472432
r15            0x62bf01 6471425
rip            0x7ffff6354b66   0x7ffff6354b66 <opencog::PythonEval::getPyAtomspace(opencog::AtomSpace*)+6>
eflags         0x206    [ PF IF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0

看起来 callq 是使用 %rip 寄存器进行的寄存器相对调用，其值为 0x7ffff6354b66 和偏移量 0x206929。

(gdb) disas /r 0x7ffff6354b66+0x206929,+10
Dump of assembler code from 0x7ffff655b48f to 0x7ffff655b499:
   0x00007ffff655b48f <_ZN7opencog10PythonEval17singletonInstanceE+7>:  00 01   add    %al,(%rcx)
   0x00007ffff655b491 <_ZZN7opencog10PythonEval4initEvE19eval_already_inited+0>:    01 00   add    %eax,(%rax)
   0x00007ffff655b493:  00 00   add    %al,(%rax)
   0x00007ffff655b495:  00 00   add    %al,(%rax)
   0x00007ffff655b497:  00 00   add    %al,(%rax)
End of assembler dump.

和原始内存转储:

(gdb) x/10 0x7ffff6354b66+0x206929
0x7ffff655b48f <_ZN7opencog10PythonEval17singletonInstanceE+7>: 0x00010100  0x00000000  0x00000000  0x00000000
0x7ffff655b49f <_ZL40__pyx_f_7opencog_9atomspace_py_atomspace+7>:   0x6213f000  0x00000000  0x6213f800  0x00000000
0x7ffff655b4af <_ZN5boost4asio5errorL17addrinfo_categoryE+7>:   0x62140000  0x00000000

然后使用si单步执行:

(gdb) si
0x00007ffff6354b69  160         pyAtomSpace = py_atomspace(atomspace);
   0x00007ffff6354b66 <routine+6>:  48 89 f7    mov    %rsi,%rdi
=> 0x00007ffff6354b69 <routine+9>:  ff 15 29 69 20 00   callq  *0x206929(%rip)        # 0x7ffff655b498 <_ZL40__pyx_f_7opencog_9atomspace_py_atomspace>
   0x00007ffff6354b6f <routine+15>: 48 89 c3    mov    %rax,%rbx
(gdb) si
[2015-02-24 01:43:14:072] [INFO] PythonEval atomspace 1
0x0000000000000000 in ?? ()
=> 0x0000000000000000:  Cannot access memory at address 0x0

鉴于上述所有情况，我不确定零取消引用从何而来，但我一直不熟悉 Linux 上的 X86 汇编器。

它的行为就像加载包含它的动态库时 cython 代码没有正确链接一样。或者其他的东西？知道为什么调用 py_atomspace cython 例程会导致此崩溃吗？我在上面遗漏了一些明显的东西吗？还是出了什么问题？

我还应该提到，上面的代码在很多情况下都工作得很好，只是在我改变了Python初始化的一些方式之后，我才遇到了上面的崩溃。因此，我试图弄清楚我的更改如何影响此调用，因为我没有对 cython 代码 py_atomspace 或 py_atomspace 的调用者进行任何更改。

Answer 1

事实证明，即使您需要在一个地方初始化 Python，Cython 也必须在很多地方初始化。

您需要调用 Cython 生成的导入函数，在 OpenCog 的情况下:

import_opencog__atomspace();

和

import_opencog__agent_finder();

在每个共享库中调用 Cython 代码中声明为“api”的函数。否则，您会在第一次调用该共享库中的该函数时发生崩溃。正如您在上面看到的，SIGSEGV 不会留下有用的堆栈跟踪。它只是两条汇编指令和寄存器相关的 callq 段错误。你知道它在 api 调用中崩溃了，是的，但是当你验证你确实在调用导入函数时，天哪，你刚刚单步执行了它，它仍然崩溃了。调用它是不够的，您需要在该共享库中调用它。

Cython 文档根本没有提到这一点(至少在我提交拉取请求来解决这个问题之前)。