GDB使用gunicorn核心转储空回溯

我试图在一个docker容器中做一个gunicorn的核心转储,并在另一个容器中进行debugging。 Gunicorn运行python3.5。 当我在转储的容器中打开核心文件时,一切都很正常:

Reading symbols from /opt/pyenv/versions/3.5.0/bin/python3.5...done. [New LWP 786] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/opt/pyenv/versions/3.5.0/bin/python3.5'. #0 0x00007f7caec93af3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007f7caec93af3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f7cacdaf213 in pyepoll_poll (self=0x7f7ca5aa9a80, args=<optimized out>, kwds=<optimized out>) at /tmp/python-build.20160412233915.330/Python-3.5.0/Modules/selectmodule.c:1549 #2 0x00000000005a7579 in PyCFunction_Call (func=func@entry=0x7f7c98706090, args=args@entry=0x7f7c9feb5550, kwds=kwds@entry=0x0) at Objects/methodobject.c:98 ... 

但是当我试图在另一个容器中打开这个文件来进行debugging时,我得到了这个:

 Reading symbols from /opt/pyenv/versions/3.5.0/bin/python3.5...done. warning: exec file is newer than core file. [New LWP 356] warning: Unexpected size of section `.reg-xstate/356' in core file. Core was generated by `/opt/pyenv/versions/3.5.0/bin/python3.5'. warning: Unexpected size of section `.reg-xstate/356' in core file. #0 0x00007fb1e8695af3 in ?? () (gdb) bt #0 0x00007fb1e8695af3 in ?? () #1 0x00007fb1e67b1213 in ?? () #2 0x000000000225b588 in ?? () #3 0x0034e2b269edb810 in ?? () #4 0x00000000000003ff in ?? () #5 0x0000000400000001 in ?? () 

我不明白为什么我会得到空的回溯。 也许有人可以帮助我呢? 谢谢!

在另一个容器中,我为了debugging目的而构build的,我有这个:

目前还不清楚“我为debugging而build”的意思。

通常,用于分析核心转储的二进制文件必须与产生该核心转储文件的二进制文件完全匹配。

这意味着你不能这样做:

 gcc -O2 -o foo tc ./foo # crashes, produces core dump gcc -g -o foo-g tc # note lack of -O2 gdb ./foo-g core # will not work! 

相反,你应该做的是这样的:

 gcc -g -O2 -o foo-g tc # optimize with debug info cp foo-g foo strip -g foo # make a production binary by removing debug info ./foo # crashes, produces a core dump gdb ./foo-g core # this works! 

为了testing这两个二进制文件是否足够“相同”,你可以比较它们的符号,例如

 diff <(readelf -Ws foo-g) <(readelf -Ws foo) 

debugging二进制文件可以有不存在于被剥离的二进制文件中的符号(例如LOCAL函数),但是在二进制文件中出现的符号必须具有相同的值。

我猜测你的“为debugging而build”的python3.5和你的“production” python3.5是不一样的。