记一次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会得到浮点数。

你可能感兴趣的:(记一次Lua死循环查错)