c++ - PyString_FromStringAndSize 导致段错误

Question

我有一个奇怪的 python 段错误。这是有问题的代码:

const std::string &fullName = child.getFullName();
const char *fName = fullName.c_str();
const int len = fullName.size();

printf(":: %02d --> %s\n", len, fName);

PyObject *item = PyString_FromStringAndSize(fName, len);
PyList_Append( list, item);

我把 printf 放在那里，希望得到提示。但是长度和 fName 值是正确的。那里没有空值!

这是我从 gdb 得到的跟踪:

#0  0x0000000000423e00 in PyObject_Malloc ()
#1  0x0000000000513a3f in PyString_FromStringAndSize ()
#2  0x00007ffff554aa5e in recurseObject (list=0x9f5f38, obj=...)
    at file.cpp:59
#3  0x00007ffff554aa74 in recurseObject (list=0x9f5f38, obj=...)
    at file.cpp:62
#4  0x00007ffff554aa74 in recurseObject (list=0x9f5f38, obj=...)
    at file.cpp:62
#5  0x00007ffff554ad27 in listObjects (self=<optimized out>, args=<optimized out>)
    at file.cpp:73

有什么想法吗？我试着环顾四周，但找不到关于这个主题的任何精确信息。

编辑:只是为了给这个问题增加更多的模糊性。只有当我在脚本中使用它时才会出现此错误。当我在 Python 中从命令行调用它时，一切正常!

编辑:这是我从 valgrind 得到的:

==27681== Invalid read of size 8
==27681==    at 0x423E00: PyObject_Malloc (in /usr/bin/python2.7)
==27681==    by 0x513A3E: PyString_FromStringAndSize (in /usr/bin/python2.7)
==27681==    by 0x7953DB4: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:55)
==27681==    by 0x7953DCA: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:58)
==27681==    by 0x7953DCA: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:58)
==27681==    by 0x7953F26: iArchive_getIdentifiers(_object*, _object*) (iarchive.cpp:69)
==27681==    by 0x498909: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x498601: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x498601: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x49F1BF: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==27681==    by 0x4A9080: PyRun_FileExFlags (in /usr/bin/python2.7)
==27681==    by 0x4A9310: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==27681==  Address 0xffffffffffffff00 is not stack'd, malloc'd or (recently) free'd
==27681== 
==27681== 
==27681== Process terminating with default action of signal 11 (SIGSEGV)
==27681==  Access not within mapped region at address 0xFFFFFFFFFFFFFF00
==27681==    at 0x423E00: PyObject_Malloc (in /usr/bin/python2.7)
==27681==    by 0x513A3E: PyString_FromStringAndSize (in /usr/bin/python2.7)
==27681==    by 0x7953DB4: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:55)
==27681==    by 0x7953DCA: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:58)
==27681==    by 0x7953DCA: recurseObjectChildren(_object*, Alembic::Abc::v4::IObject const&) (iarchive.cpp:58)
==27681==    by 0x7953F26: iArchive_getIdentifiers(_object*, _object*) (iarchive.cpp:69)
==27681==    by 0x498909: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x498601: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x498601: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==27681==    by 0x49F1BF: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==27681==    by 0x4A9080: PyRun_FileExFlags (in /usr/bin/python2.7)
==27681==    by 0x4A9310: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==27681==  If you believe this happened as a result of a stack
==27681==  overflow in your program's main thread (unlikely but
==27681==  possible), you can try to increase the size of the
==27681==  main thread stack using the --main-stacksize= flag.
==27681==  The main thread stack size used in this run was 8388608.
==27681== 
==27681== HEAP SUMMARY:
==27681==     in use at exit: 5,126,103 bytes in 5,336 blocks
==27681==   total heap usage: 14,574 allocs, 9,238 frees, 12,498,954 bytes allocated
==27681== LEAK SUMMARY:
==27681==    definitely lost: 76 bytes in 3 blocks
==27681==    indirectly lost: 240 bytes in 10 blocks
==27681==      possibly lost: 671,180 bytes in 1,124 blocks
==27681==    still reachable: 4,454,607 bytes in 4,199 blocks
==27681==         suppressed: 0 bytes in 0 blocks
==27681== Reachable blocks (those to which a pointer was found) are not shown.
==27681== To see them, rerun with: --leak-check=full --show-reachable=yes

不太清楚那是什么意思!而且我仍然不明白为什么它在那里失败。我尝试了不同的方法，例如克隆字符串 fullName 以确保它是分配的新内存。甚至使用了一个新的 char[] 并在其中复制了全名。仍然是同样的问题，在同一个地方。

有人知道吗？它在 Python 中很常见吗？

Answer 1

我不知道该如何解释，但这肯定是因为堆之前某处已损坏。所以我设法追踪到错误的来源。

FTW:类似于:

Bob bob;
new (&bob) Bob(someParameter);

可能不是那么安全!在某些情况下，它是完美的，但并非无处不在。