最近，项目在越南版删档测试的时候，发生了罕见的coredump，简单记一点排查日志

目前的敏感词过滤是在C层做判定的，先后经过几个项目考验，模块算是比较稳定了。越南版有个需求，需要将敏感词里的空格去掉。比如敏感词是abc，现在不能说abc了，但是玩家可以输入“a b c”，所以需要过滤掉空格。有同事就对C层改了一下，判断rune是32的时候，就继续判断后续字符，出事的代码大致如下：

　　　　　　　　lua_rawgeti(L, 1, j);
　　　　　　　　uint32_t rune = (uint32_t)lua_tointeger(L, -);

• if (rune == ) {
• continue;
• }

lua_pop(L, );

         if(node == NULL) {  
             node = table\_get(dict, rune);  
         } else {

这里会跳过lua_pop语句，导致之前lua_rawgeti的结果残留在栈上。但这个缺陷不会马上让进程挂掉，而是将栈弄坏一点点。我们来看Lua的栈定义：

/*
** 'per thread' state
*/
struct lua_State {
CommonHeader;
unsigned short nci; /* number of items in 'ci' list */
lu_byte status;
StkId top; /* first free slot in the stack */
global_State *l_G;
CallInfo *ci; /* call info for current function */
const Instruction *oldpc; /* last pc traced */
StkId stack_last; /* last free slot in the stack */
StkId stack; /* stack base */
UpVal *openupval; /* list of open upvalues in this stack */
GCObject *gclist;
struct lua_State *twups; /* list of threads with open upvalues */
struct lua_longjmp *errorJmp; /* current error recover point */
CallInfo base_ci; /* CallInfo for first level (C calling Lua) */
volatile lua_Hook hook;
ptrdiff_t errfunc; /* current error handling function (stack index) */
int stacksize;
int basehookcount;
int hookcount;
unsigned short nny; /* number of non-yieldable calls in stack */
unsigned short nCcalls; /* number of nested C calls */
l_signalT hookmask;
lu_byte allowhook;
};

lua_State的stack是一个指针，指向一个动态申请的TValue指针数组。这个栈不仅是lua和C交互的时候，用于双方交换数据；lua函数调用的时候，也会将函数参数压栈（当然，调用关系不在这个栈上，而是通过CallInfo指针组织的双向链表来记录）Lua默认会给函数初始化20个格子，也可以通过lua_checkstack函数去增加栈的大小。L->top指向的是栈上的第一个可用空槽，L->top在正常使用的时候会小于L->ci->top，lua自带有api_check来检查。之前为了压榨性能，api_check也关掉了，所以没检查出stack overflow。

当一个C函数不断往栈上push函数，超过栈的大小后，会写坏什么内存就没法确定了。出事的时候，写坏的是另一个协程的stack，另一个协程正准备resume回来，但是栈上存的ci->func是TValue（正数32），不是一个函数类型，就coredump了。

稳妥起见，以后改C代码还是走一下code review吧，自己也打开api_check检查一下。。查这个问题花了很久，还有一个原因是其他同学搞混了线上版本，我看的是有问题的版本，结果另一个分支上的是没问题的版本，以为正式服上跑的是没问题的版本，查了好久。。。