【发布时间】：2019-02-14 22:08:56
【问题描述】：
一个python服务器进程当前经常（每隔几天）崩溃，cpu使用率很高，但没有主动处理任何东西。该进程在 alpine linux docker 中运行。
为了帮助找到问题，我想查看进程繁忙的确切线路。由于该进程已经在运行，我相信我唯一的选择是使用通用的gdb 调试器。
现在我尝试关注this small guide，为 alpine linux “改编”：我注意到 gdb 已经安装，并且 python3 调试符号在这个包中：python3-dbg。
现在，如果我运行（显然从 thwich python 运行到虚拟环境之后）。 gdb python3 -p 135（其中135是docker中的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 符号，就不可能找到导致挂起的哪一行？
【问题讨论】：
-
这个答案似乎非常有帮助：stackoverflow.com/a/14905356/769971 21+ 帧中大量缺失的符号让我有点担心，但我想这些只是 libpython.so 调用的一些缺失符号。跨度>
-
@wholevinski 在那个答案中，似乎正在运行的进程中的
py-xxx仍然不可用。我猜它是这样工作的：gdb可以在启动新进程但不附加到正在运行的进程时执行py-xxx。 -
@Sraw 是的，但随后他将与 python 2.7 捆绑在一起的 gdb 目录插入到他的路径中，他似乎可以执行 py-bt。我自己没有尝试过，所以我只是盲目地相信那个人写的东西。
标签： python python-3.x gdb gevent alpine