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

Question

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

PyObject * pyAtomSpace;

if (atomspace)
    pyAtomSpace = py_atomspace(atomspace);

来自：

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

它在调用 cython 例程的最后一行崩溃，该例程用 python 对象和以下 cython 代码包装 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 没有留下有用的堆栈跟踪。它只是两个汇编指令和 boom，寄存器相关的 callq 段错误。你知道它在 api 调用中崩溃，是的，但是当你验证你确实在调用导入函数时，见鬼你只是单步执行它，它仍然崩溃。调用它是不够的，您需要在该共享库中调用它。

并且 Cython 文档根本没有提及这一点（至少在我提交我的 pull request 以修复它之前）。

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

Debugging crash in Cython code called from C++

c++

python-2.7

crash

cython