在 C 层面制造出崩溃的可能性并不是很多，数据越界是一类常见的 bug (此次并不像);另一类是内存治理掉足，比如对同一个指针 free 多次，导致内存治理器掉足，把同一个地址分派给两个地位，导致两个对象地址重叠。后一类问题能干扰到 C 的 stack frame 可能性比较小，除非有堆上的对象指针指向了栈地址，然后并引用。此次的 bug 中，最打的线索是 L->errorJmp ，也就是 lua 线程中指向恢复点的 jmp_buf ，它是在 C 栈上的。
L 中有一些相干变量可以推想 resume/yield/pcall 等的履行状况： L->nny L->nCcalls L->ci->callstatus 等都是。我分析的结不雅是在 auxresume 返回后，没有持续运行 luaB_coresume 中的 push boolean 过程，却竽暌怪运行了新的一轮 luaD_pcall ，导致了最终的崩溃。这可以经由过程 L 的 errorJmp 的 status 获得必定的佐证。不过 C stack 膳绫腔有 luaB_coresume 的返回地址比较难解释，只能说是可能被缺点的运行流程覆盖掉落了。
gc 会是触发 bug 的多发点，因为 gc 是平行于主流程同步进行的。此次崩溃点的子线程的 lua 栈帧逗留在 yield 函数上，在此之前也切实其实调用了 gc step 。然则，我们可以经由过程查阅 L 的 gcstate 变量查看 gc 处于什么阶段。在此次的事发明场，可以看到 gcstate 为 GCSpropagate 也就是 mark 阶段，所以并不会激发任何 __gc 流程，也没有内存释放。
结论：对于 bug ，临时没有结论。不过对于调试 lua 编写的法度榜样，照样积聚了一些经验：
- 必定要在编译 lua 时加 -g ，固然 lua 本身出严重 bug 的可能性极低，但可以便利在出问题时用 gdb 分析。
- 在 gdb 中查看 lua 的调用栈很有意义，分析 L->ci 很轻易拿到调用栈信息。
- 记得查看一下 lua 的数据栈内容，包含已经 pop 出去，但还残留在内存中的数据，可以赞助分析崩溃时的状况。
- 记得查看 L 中保存的 gcstate GCdebt 等 gc 相干变量，可以用于揣摸 lua gc 的工作状况。
- L 中的 nny nCcalls errorJmp 可以赞助肯定 lua 到 C 的调用层次。留意：一个 yield 状况的 coroutine ，errorJmp 指针应当为 NULL 。
别的，gdb 分析 skynet 可以大年夜下面的线索入手：
- context 对象里能找到当前办事的地址、最后一个向外提起的请求的 session 、接收过若干条消息等。结合 log 文件来看会有参考价值。
- 如不雅想找到内存中其它的办事对象(非当前哨程上晃荡的)，可以尝尝 p *H 。 H 是个数组，定义在 skynet_handle.c 中，琅绫擎有所有办事的地址。
- 如不雅想找到内存中待唤醒的 timer ，可以尝尝 p *TI 。它定义在 skynet_timer.c 中。
【编辑推荐】
- 前端开辟JS：事宜轮回机制、调用栈以及义务队列
- 前端开辟js运算符单竖杠“|”的用法和感化及js数据处理
- Node.js对于Java开辟者而言是什么？
- 应用嵌入式开辟板实现对车位锁控制的流程及法度榜样实现
- 2017年前端开辟对象趋势
推荐阅读
OpenStack已经进入第七年了，如今治理着跨越500万个处理器核心。它的增长在很大年夜程度上与私有云安排有关。而如今，OpenStack基金会称，企业须要为私有云2.0做好预备，因为下一代技巧的>>>详细阅读
本文标题：用gdb分析coredump的一些技巧
地址：http://www.17bianji.com/lsqh/35135.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示