Lua使用os.date函数也要小心 推荐
2014-04-10 12:02
411 查看
前段时间,在给我们游戏服务器写lua的脚本的时候,发现了一个奇怪的现象,一段lua代码只要一执行就把服务器给搞挂了,仔细分析了一下,发现这段lua代码并没有执行什么特别的操作,甚至都没有跟我们服务器的C++层交互,仅仅只是使用lua自身的一些库函数,而且只对windows平台下的服务端会产生这个崩溃。初步认为是windows平台的原因。于是我在windows平台下编译了lua的源码,跟进去后发现原来是宕在了windows的CRT函数里,解释一下CRT是windows的C运行时库,如果有朋友不清楚,可以看看《程序员自我修养》这本书中关于运行时库的章节,正好网上给出的示例章节就是这有这一章,可以看这里:http://book.51cto.com/art/200904/120986.htm
接着说我的问题,宕在了一次调用lua内置的os库的date()函数,调用如下:
打开,因为我们的服务端编的都是debug版本,vs编debug版默认使用的多线程的那个debug版本的库:
打开源码找到对应的 strftime 函数,然后一路跟进去,最后终于找到了罪魁祸首!尼玛居然有一行 ASSERT!
最后就因为这个ASSERT,我们的服务端光荣的挂了,而且我们外网的服务端就用的是debug版本,不过幸好 glibc 的库下不存在这个问题。
既然都看到这里了,我就顺带对比了一下,vs这个版本的CRT库里strftime能够支持的字符和标准有什么区别:
CRT能够支持的字符有:aAbBcdHIjmMpSUwWxXyYZz%'\004''\015'
而最新的c和c++可以支持的果然更多,可以在cplusplus.com对比一下:http://www.cplusplus.com/reference/ctime/strftime/
接着说我的问题,宕在了一次调用lua内置的os库的date()函数,调用如下:
os.date("%C")跟进lua源码后发现,源码里最后调用了C库的strftime函数:
打开,因为我们的服务端编的都是debug版本,vs编debug版默认使用的多线程的那个debug版本的库:
打开源码找到对应的 strftime 函数,然后一路跟进去,最后终于找到了罪魁祸首!尼玛居然有一行 ASSERT!
最后就因为这个ASSERT,我们的服务端光荣的挂了,而且我们外网的服务端就用的是debug版本,不过幸好 glibc 的库下不存在这个问题。
既然都看到这里了,我就顺带对比了一下,vs这个版本的CRT库里strftime能够支持的字符和标准有什么区别:
CRT能够支持的字符有:aAbBcdHIjmMpSUwWxXyYZz%'\004''\015'
而最新的c和c++可以支持的果然更多,可以在cplusplus.com对比一下:http://www.cplusplus.com/reference/ctime/strftime/
相关文章推荐
- lua时间函数操作和对比代码,os.date() os.time()
- 不要在Lua中使用os.clock()函数
- lua时间函数操作和对比代码,os.date() os.time()
- Lua中os库的使用(execute,date,clock,time)
- sql DATEPART函数使用
- excel countif 函数使用的时候小心
- Oracle -- sysdate的使用函数的方法
- DB2 DATE类型在显示的时候,带有00:00:00,去掉的方法,使用VARCHAR()函数
- ucosII的CPU使用率查看即OSStatInit()函数的使用方法
- Script.lua__os.date
- os、os.path 模块中关于文件、目录常用的函数使用方法
- Python使用os.listdir()函数来得目录内容的介绍
- sql DATEPART函数使用
- LUA 比较两个时间点(os.date())之间的时间间隔值
- os、os.path 模块中关于文件、目录常用的函数使用方法
- MySQL中ADDDATE()函数的使用教程
- os、os.path模块中关于文件、目录常用的函数使用方法
- php使用date()函数时,提示的警告
- 改善C++ 程序的150个建议学习之建议20:使用memcpy()系列函数时要足够小心
- 使用to_date创建函数索引的时候经常会遇到ORA-01743错误