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在Python中很普遍嗎？

Answer 1

我不知道如何解釋這一點，但這是肯定的原因，因爲這堆在之前的某個地方已經被破壞了。所以我設法追蹤錯誤的來源。

FTW：是這樣的：

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

可能不是超級安全！在某些情況下，它是完美的，但不是無處不在。