mysql 递归 不用recursive_MySQL代码学习第九——maximum recursion depth exceeded

前面发的Python扩展gdb的代码，当触发断点次数很多（几百）次的时候，就会报这个错：

Python Exception <type 'exceptions.RuntimeError'> maximum recursion depth exceeded while calling a Python object

这是递归调用的层数太多了，但是我的代码里有递归调用？

猜测了一会儿，推断是这句引起的：

    #在gdb中执行c命令(continue)
    gdb.execute('c')

上面这段是在我的comm函数中，而该函数是我告诉gdb在触发断点的时候调用。

#在gdb中注册本python文件中的comm函数，在断点触发时调用
gdb.events.stop.connect(comm)

可能就是函数中comm中执行了gdb.execute('c')，又触发了断点，再调用comm。。。。以此类推。

把gdb.execute('c')注释掉以后，果然一直continue也不会报上面的错误了。

因此要把gdb的执行过程改一下：

[root@localhost source]# cat mysqlmtr.gdb 
set height unlimited
b mtr_t::start
b mtr_t::commit
source /data/source/bt_graph_data.py
r --defaults-file=/data/mysql8015/my.cnf
set $count = 0
while $count < 10000
    set $count = $count +1
    c
end

注意set height unlimited是为了不出现这个提示：

--Type <RET> for more, q to quit, c to continue without paging--

这个提示会在gdb输出比较多的时候出现，要等待键盘输入才能继续。

用下面的命令启动gdb：

[root@localhost source]# gdb -x mysqlmtr.gdb /usr/local/mysql80/bin/mysqld

这样gdb就设置好了断点，也装载了python脚本，启动了mysqld，并且不断地自动continue。

在做这些工作之前，还仔细看了一下gdb的tracepoint。虽然可以不用等待输入就可以收集一些信息，但是貌似不能记录backtrace，也就是调用栈信息。不满足我的需求。

到现在为止，为了跟踪mysqld，用python代码对gdb扩展，基本成型了。还有两个需求需要实现：

1. 要以某种方式收集变量的值，并且在展示的界面也要能够展示出来
2. 可以收集多个mysql客户端的输入输出，并且也能展示出来

总的目标还是提高跟踪mysqld源码的效率，以直观的方式展示出来，并且展示结果容易共享，成为有价值的资料。

而jupyter notebook本身具有这个特点，而且我理解应该是pyecharts也做了相当的支持工作。

下载为html。看了一下，里面貌似是有echarts的实现。这样保存下来的html就不需要有什么依赖环境了，有浏览器就可以打开。可以方便地查看各个图，并且对这些图可以有放大、缩小、移动等等操作。容易看清楚了。