使用PyString_FromStringAndSize导致段错误
我在使用Python时遇到了一个奇怪的段错误(segfault)。这是出问题的代码:
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中常见吗?
1 个回答
0
我不知道该怎么解释,但这肯定是因为之前某个地方的堆出了问题。所以我设法找到了错误的来源。
顺便提一下:类似这样的代码:
Bob bob;
new (&bob) Bob(someParameter);
可能并不是特别安全!在某些情况下,它是完美的,但并不是在所有地方都适用。