[英]gdb debugging python (3) process on alpine linux, can't use py-list
很好,python服務器進程目前經常(每隔幾天)崩潰,CPU使用率很高,但沒有主動處理任何事情。 該過程在高山linux docker中運行。
為了幫助發現問題,我想查看該進程正好在哪一行。 由於該進程已經在運行,我相信我唯一的選擇是使用通用gdb
調試器。
現在,我嘗試按照適用於高山linux的這個小指南進行 “調整”:我注意到已經安裝了gdb
,並且python3調試符號位於此軟件包中: python3-dbg 。
現在,如果我運行(顯然是從運行python到虛擬環境之后)。 gdb python3 -p 135
(其中135是gdb python3 -p 135
中的python后台進程)。
在產生的gdb進程中,我嘗試列出當前正在執行的python行: py-list
。 但是,這將返回“未定義的命令:py-list”。 與堆棧跟蹤類似: py-bt
,也找不到此命令。 我可以解決這個問題嗎?
當我使用更基本的bt
命令時,我看到:
#0 0x00007fe3dd7e0c3d in epoll_pwait () from /lib/ld-musl-x86_64.so.1
#1 0x00007fe3dc90c3a0 in signals () from /njs/BackgroundServer/venv/lib/python3.6/site-packages/gevent/libev/corecext.cpython-36m-x86_64-linux-gnu.so
#2 0x00007fe3dc90c490 in default_loop_struct () from /njs/BackgroundServer/venv/lib/python3.6/site-packages/gevent/libev/corecext.cpython-36m-x86_64-linux-gnu.so
#3 0x00007fe3dc6e57a1 in epoll_poll (loop=0xe95f, timeout=<optimized out>) at /tmp/pip-install-o4b63_go/gevent/deps/libev/ev_epoll.c:153
#4 0x00007fe3dc6eda5c in ev_run (loop=0x7fe3dc90c3a0 <default_loop_struct>, flags=flags@entry=0) at /tmp/pip-install-o4b63_go/gevent/deps/libev/ev.c:3683
#5 0x00007fe3dc6ede88 in __pyx_pf_6gevent_5libev_8corecext_4loop_14run (__pyx_v_self=0x7fe3d8e86840, __pyx_v_once=<optimized out>, __pyx_v_nowait=<optimized out>)
at src/gevent/libev/gevent.corecext.c:5575
#6 __pyx_pw_6gevent_5libev_8corecext_4loop_15run (__pyx_v_self=0x7fe3d8e86840, __pyx_args=<optimized out>, __pyx_kwds=<optimized out>) at src/gevent/libev/gevent.corecext.c:5526
#7 0x00007fe3dd3d8b46 in _PyCFunction_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#8 0x00007fe3dd3d8db9 in _PyCFunction_FastCallKeywords () from /usr/lib/libpython3.6m.so.1.0
#9 0x00007fe3dd42f7fd in ?? () from /usr/lib/libpython3.6m.so.1.0
#10 0x00007fe3dd435634 in _PyEval_EvalFrameDefault () from /usr/lib/libpython3.6m.so.1.0
#11 0x00007fe3dd42ee0c in ?? () from /usr/lib/libpython3.6m.so.1.0
#12 0x00007fe3dd43668c in _PyFunction_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#13 0x00007fe3dd3a25e0 in _PyObject_FastCallDict () from /usr/lib/libpython3.6m.so.1.0
#14 0x00007fe3dd3a2870 in _PyObject_Call_Prepend () from /usr/lib/libpython3.6m.so.1.0
#15 0x00007fe3dd3a24e7 in PyObject_Call () from /usr/lib/libpython3.6m.so.1.0
#16 0x00007fe3dc910289 in g_initialstub (mark=mark@entry=0x7ffc48bd3e00) at greenlet.c:810
#17 0x00007fe3dc90fdba in g_switch (target=0x7fe3d8eb85a0, args=0x7fe3ddc0d048, kwargs=<optimized out>) at greenlet.c:582
#18 0x00007fe3dd3cea91 in ?? () from /usr/lib/libpython3.6m.so.1.0
#19 0x00007fe3dd3c13d0 in ?? () from /usr/lib/libpython3.6m.so.1.0
#20 0x00007fe3dd42f5dd in ?? () from /usr/lib/libpython3.6m.so.1.0
#21 0x00007ffc48bd4118 in ?? ()
#22 0x00007ffc48bd4080 in ?? ()
#23 0x0000000000000002 in ?? ()
#24 0x0000000000000002 in ?? ()
#25 0x00007fe3dd3e402f in ?? () from /usr/lib/libpython3.6m.so.1.0
#26 0xd1145828f949d59e in ?? ()
#27 0x00007ffc48bd40d0 in ?? ()
#28 0x00007fe3dd4ae93a in ?? () from /usr/lib/libpython3.6m.so.1.0
#29 0x0000000000000003 in ?? ()
#30 0x0000000000000000 in ?? ()
但是我注意到,當我多次運行bt
,stacktrace中的內存地址根本不會改變,因此這似乎意味着它實際上一直在等待gevent返回? 我想如果沒有python符號,就不可能找到導致掛起的行?
問題是Alpine不包含也不自動加載用於實現此命令的gdb的Python模塊。
對於Python 2.7問題,我下載了Python 2.7源代碼,其中包含文件Python-2.7.15/Tools/gdb/libpython.py
。 使用環境變量PYTHONPATH
包括包含該文件的目錄)啟動gdb,然后在gdb中執行python import libpython
。
Python 3應該類似,盡管我還沒有確切確認Python 3源代碼分發文件中的文件名。
看來Alpine的cython2
和cython3
軟件包包含libpython.py
,盡管我不知道它們是否完全等效。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.