罕见的coredump了

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

 

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

　　　　　　　　lua_rawgeti(L, 1, j);             
　　　　　　　　uint32_t rune = (uint32_t)lua_tointeger(L, -1);                                   
+            if (rune == 32) {                                                                 
+                continue;                                                                     
+            }                                                                                 
             lua_pop(L, 1);                                                                    
-
             if(node == NULL) {                                                                
                 node = table_get(dict, rune);                                                 
             } else {

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

 1 /*
 2 ** 'per thread' state
 3 */
 4 struct lua_State {
 5   CommonHeader;
 6   unsigned short nci;  /* number of items in 'ci' list */
 7   lu_byte status;
 8   StkId top;  /* first free slot in the stack */
 9   global_State *l_G;
10   CallInfo *ci;  /* call info for current function */
11   const Instruction *oldpc;  /* last pc traced */
12   StkId stack_last;  /* last free slot in the stack */
13   StkId stack;  /* stack base */
14   UpVal *openupval;  /* list of open upvalues in this stack */
15   GCObject *gclist;
16   struct lua_State *twups;  /* list of threads with open upvalues */
17   struct lua_longjmp *errorJmp;  /* current error recover point */
18   CallInfo base_ci;  /* CallInfo for first level (C calling Lua) */
19   volatile lua_Hook hook;
20   ptrdiff_t errfunc;  /* current error handling function (stack index) */
21   int stacksize;
22   int basehookcount;
23   int hookcount;
24   unsigned short nny;  /* number of non-yieldable calls in stack */
25   unsigned short nCcalls;  /* number of nested C calls */
26   l_signalT hookmask;
27   lu_byte allowhook;
28 };

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检查一下。。查这个问题花了很久，还有一个原因是其他同学搞混了线上版本，我看的是有问题的版本，结果另一个分支上的是没问题的版本，以为正式服上跑的是没问题的版本，查了好久。。。

posted on 2019-10-27 00:11  lifehacker  阅读(1043)  评论(2)  编辑  收藏  举报

导航