gdb在高山linux上调试python(3)进程，不能使用py-list

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是docker中的python后台进程)。

在生成的gdb进程中，我试图列出当前正在执行的python行：py-list。但是，这将返回"未定义的命令：py-list"。与堆栈跟踪类似：py-bt，也找不到此命令。
我可以解决这个问题吗？

当我使用更基本的bt命令时，我看到：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#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符号，就不可能找到导致挂起的行？