與GDB

Question

Python的內存調試我們有一個Linux應用程序，使得使用OpenSSL的Python綁定的，我懷疑這是導致隨機崩潰。有時，我們看到它與消息崩潰：

Python Fatal Error: GC Object already tracked

這似乎是無論是在圖書館的一部分編程錯誤，或內存損壞的症狀。給定一個核心文件，有什麼方法可以知道它執行的最後一行Python源代碼？或者如果它附加在GDB中？我意識到它可能是所有編譯的字節碼，但我希望有人可能已經處理了這個。目前它正在跟蹤模塊處於活動狀態，我們希望它會再次發生，但可能會持續很長時間。

Answer 1

是的，你可以做這樣的事情：

(gdb) print PyRun_SimpleString("import traceback; traceback.print_stack()") 
    File "<string>", line 1, in <module> 
    File "/var/tmp/foo.py", line 2, in <module> 
    i**2 
    File "<string>", line 1, in <module> 
$1 = 0 

這也應該是可以使用在Python gdbinit文件中定義的pystack命令，但它不是爲我工作。如果你想研究它，它會被討論here。另外，如果您懷疑存在內存問題，值得注意的是，如果您準備重新編譯它，則可以使用valgrind與python。描述的過程here.

Answer 2

如果你有mac或sun box踢，你可以使用dtrace和用dtrace編譯的python版本來弄清楚當時應用程序正在做什麼。注意：在10.5 python是預編譯的dtrace，這真的很好，方便。

如果無法提供給你，那麼你可以import gc並啓用調試，你可以放出去，到日誌文件。

具體回答您的關於與GDB，你可能需要閱讀「Debugging With GDB」蟒維基調試問題。

Answer 3

如果您使用CDLL在Python中打包C庫，並且這是64位的Linux，那麼很有可能您的CDLL包裝配置錯誤。 CDLL默認爲所有平臺上的int返回類型（在64位系統上應該是long long），並且只是希望您傳遞正確的參數。在這種情況下，您可能需要驗證CDLL包裝器...

Answer 4

除了上述所有可以很快實現通過trace module即席示蹤劑。