使用GDB来调试Python里optimized out的问题

首先，贴点网友们的经验：

http://www.cnblogs.com/dkblog/p/3806277.html

https://blog.alswl.com/2013/11/python-gdb/

http://blog.csdn.net/wangzuxi/article/details/42317827

这几个帖子里把基本用法都讲得很明白了。

然而，在现网服务器gdb调试python时，却因为缺少乱七八糟的库而无法分析。

所以，最靠谱的办法是gdb generate-core-file 生成core文件，拖回开发机上面分析。

然后，又因为开发机linux发行版比较特殊，死活装不上python的dbg脚本，于是只能人肉跑去ubuntu里拖过来，放到开发机里。我放了一个修改版的到github里了。

https://gist.github.com/talebook/8958c7f6fc87c08084a47475264de08e

GDB会根据执行程序的路径，自动加载/usr/lib/debug/xxx目录的对应的gdb脚本；我的python是软链到 usr/local/services/python/bin/python2.7.py的，所以脚本要放到这个路径：

/usr/lib/debug/usr/local/services/python/bin/python2.7-gdb.py

环境搞好后，就可以开心地调试python了！

======================================================

…… 然而！

(gdb) py-bt #5 (frame information optimized out) #9 (frame information optimized out)

简直一脸懵逼！

看了下gdb的脚本和python代码，发现虽然f_code参数被优化掉了，但是co参数、freevars参数还在啊，根据python代码里freevars的用法，只要-1， -2， -3地退格使用，就是对应的python代码局部变量指针地址了，so，我依葫芦画瓢搞了个py-vars命令，自动去遍历每个局部变量，然后print出来

(gdb) py-vars [ 0] self = <Server(online_db_table='cdn_host', hosts_info_flush_time=300...(truncated) [ 1] connection = <_socketobject at remote 0x7fd090dbc590> [ 2] address = ('10.121.119.91', 34501) [ 3] queue = <Queue(_writer=<_multiprocessing.Connection ...(truncated) [ 4] t3 = 1500618367.95312 [ 5] t2 = 1500618367.95312 [ 6] t1 = 1500618367.95312 [ 7] t0 = 1500618367.95312 [ 8] recv_data_len = 0 [ 9] recv_data = '1\x84\xe5\x00\x00\x00'

so，搞定！可以尽情去找代码BUG了！