记一次Lua死循环查错

前言

如果在Lua语言中某一处死循环了！你特么的怎么去查出这特么的该死的循环到底在特么的哪里！！！

重现步骤

一打开技能界面，整个游戏就卡死不动了

开始排查

查看一下cpu占用率，unity占用60%+，应该是死循环

一开始采取冒烟式查错法，去一些可疑的地方一个个打断点（我们有lua调试工具可断点）。
游戏的大循环，事件派发基层接口，lua调用c#的基层接口等等，都加了很多断点

可喜的是~~ 完全没有进来！

要怎么才知道当前运行哪段代码呢？这个问题让我想起一个东西
debug.sethook

debug库提供了一种hook的方式，可以通过注册一个handler函数，在lua脚本运行到某个调用时，会触发这个handler，
获取到相应的执行信息，并且给你一个记录和数据维护的机会。

它主要有四种事件会触发这个handler的调用：

1. 当调用一个lua函数的时候，会触发call事件
2. 当函数返回的时候，会触发一个return事件
3. 当执行下一行代码的时候，会触发一个line事件
4. 当运行指定数目的指令后，会触发count事件

我们可以通过debug.sethook这个函数来注册一个hook的handler，他有三个参数：

handler的处理函数，hook事件触发后被调用
描述需要hook的事件类型，call、return和line事件分别对应：’c’, ‘r’, ‘l’，可以互相组合成一个字符串
获取count事件的频率（可选）

根据这个函数，我可以让lua每执行一行代码，就把它的文件名已经行号输出到我的日志文件中

debug.sethook(
function (event, line)
   WriteLogToFile(debug.getinfo(2).short_src .. ":" .. line)
end
, "l")

写好这个工具后，我来到了技能界面前，开启了hook！然后打开技能界面！出现吧！死循环！

我发现我的日志文件，正在以肉眼可见的速度快速增大！

打开日志后查看后，很快就找到了一段死循环逻辑！

果然，这个害我加班的BUG, 就是我的写的！

总结

debug.sethook确实可以干很多事情，比如基于这个写一个性能监听工具，在函数call、return事件触发时，计算出这个函数的执行时间。

另外这个锅其实是我们把游戏从c#语言转换到lua语言出现的。因为语法不一样，c#那边用整形除以整形得到的还是整形，但是lua会得到浮点数。