能否支持tombstone机制

[myzhan]

目前业务上遇到了分析coredump比较麻烦的问题，因为服务端在海外的k8s集群里面，一旦coredump了，k8s不会保留现场，会直接重新拉起新的容器。一个大的coredump文件，从海外拉回来比较麻烦。

内部讨论了一下，可以在skynet内部捕获信号，在coredump的时候，把一些关键信息保存到文本，可以快速确认一下问题的范围。

参考android的tombstone机制，我实现了以下功能，如果觉得这个机制有用，我可以提一个PR。

1. 保存寄存器的值
2. 保存崩溃的线程堆栈
3. 如果在跑lua代码，把lua的堆栈也保存下来
4. 重新抛出信号，让系统生成coredump文件

[cloudwu]

这个需求和项目相关。我不希望增加维护负担。

skynet 目前可以把信号以消息形式转发给服务（目前用于 log)。如果需要更多支持，可以考虑最小维护成本的基础机制。

[fanyh]

snlua转发信号至lua 转至lua 还要考虑mq的问题， signal放在mq中解决不了上面的问题，改mq成本太大了

[myzhan]

确实，这个功能需要兼容不同操作系统，还有不同 CPU 架构的话，还挺复杂。考虑到这种情况，一般要处理的是SIGSEGV这类危险信号，最好是现场处理，不要转发。底层机制，能否允许业务设置自定义的 signal handler？

[cloudwu]

我感觉，如果只是要在 lua 编写的服务中处理 singal 的话。只需要额外编写一个 C 库调用 sigaction 注册 singal handler 。

然后在 config 里配置 preload ，保证每个 lua 服务在初始化的时候都调用这个 C 库。

这需要和 log 处理 SIGHUP 一样，在底层处理。但是不走转发的话，没想好怎么绕过任务调度器去执行一段用户定义的代码。

或许在系统启动时启动特定服务主动注册 signal handler 就可以了？

[fanyh]

如果能调用用户自定义代码， 操作空间就大很大了

[myzhan]

如果不是要支持获取 lua 堆栈，应该用 gcc 的 constructor 特性加 LD_PRELOAD 加载一下信号捕获模块，就可以了，不需要依赖 skynet 上下文。但要获取 lua 堆栈就比较 hack 了，要从 skynet_context 入手，拿到 lua state，再去遍历堆栈。

[myzhan]

上午看岔了，我目前在信号处理函数里面，是这样获取skynet_context的

int32_t current = skynet_current_handle();
// 这个拿到的不是callback context
struct skynet_context *ctx = skynet_handle_grab(current);
// 获取 snlua 结构体
void *instance = skynet_context_instance(ctx);

instance->L 没有调用栈和 upvalues，instance->activeL 有 upvalues。

[cloudwu]

我记错了。snlua 服务这里经过一次改写。并不是约定的 skynet_context 的第一个变量为 L ，其实这个 L 仅仅只是 lua 服务的主线程。但 skynet 在 lua 层注入的 callback 并不依赖这个主线程，而是单独开了一个 coroutine 运行。

https://github.com/cloudwu/skynet/blob/master/lualib-src/lua-skynet.c#L123-L138

有两个方法可以获得这个信息（ struct callback_context ）：

1. 使用 skynet callback 中的 ud 参数，转换为 struct callback_context ，它只包含一个 L 。
2. 从 lua 注册表获取 "callback_context" 项。

我感觉 2 更简单一点。

[myzhan]

试了方法 2，拿到的 callback_context 里面的 L，它的堆栈是这个。

Lua Backtrace:
----------------------------------------
#0  =[C]: in function 'cresume'
#1  @./lualib/skynet.lua:26: in function 'coroutine_resume'
#2  @./lualib/skynet.lua:1115: in function '?'
#3  =[C]: in function 'pcall'
#4  @./lualib/skynet.lua:1136: in function '?'

进一步用 lua_getlocal 拿到它的局部变量 co，再去遍历堆栈，才是实际执行中的堆栈。这一套下来有点复杂了，由于我要处理的是 coredump，内存可能是坏的，我倾向于简单用 activeL，减少处理步骤，只是尽可能地读一下 lua 堆栈，读不到还有 C 堆栈兜底。

[hanxi]

只是拿宕机堆栈是不是写个gdb脚本更简单？宕机后用gdb使用本地的core文件处理一下，可以在传输core文件前把堆栈信息先传回来。

[myzhan]

只是拿宕机堆栈是不是写个gdb脚本更简单？宕机后用gdb使用本地的core文件处理一下，可以在传输core文件前把堆栈信息先传回来。

这个方案有考虑过，主要是会在线上引入好几个依赖，例如说 gdb，gdb 的 python 脚本。目前的方式只是写成了一个 lua 库，没有外部依赖。

你这个方法有一个好处，就是 gdb 解析了调试符号，可以看到代码行号，目前我不打算在 lua 库里面搞那么重，只显示了函数名。