最近工作中有地方嵌入式程序出现莫名其妙的问题，有时候正常的变量值都会突变了导致问题。
这问题还是偶然出现的神秘莫测，若没有对内存检测的神器,很难定位。
比如char buf[5], memcpy(buf,"12345678",8) ;明显超过了buf的范围，但程序竟正常运行不会报错，也没任何提示。
这里明细写出来是为了展现问题，但项目中那么多代码和文件且分散在各处，且有的可能是中间变量拷贝，比如memcpy(buf,buf1,len1),长度len1是变动的，比如取自后台应答报文中的某个值。那么这类问题，检查代码也是难看出来的。
这也说明对涉及内存操作的地方，一定要谨慎，考虑好值的合法性问题。
c语言是强大，但是操作太灵活就是怪兽啊，类似这类的bug防不胜防。搞的我都想用两周时间用go语言重构一版终端程序。
ｇｏ语言高级语言，若类似这样的bug编译阶段都会过，比c语言应更安全和稳定。
c语言的类似这种很难发现的bug,有了asan神器，这类问题无处遁形。
对于asan,只有一个词能表达我的心情,那就是相见恨晚…asan你值得拥有,谁用谁知道。
ASAN（Address-Sanitizier）早先是LLVM中的特性，后被加入GCC 4.8，在GCC 4.9后加入对ARM平台的支持。因此GCC 4.8以上版本使用ASAN时不需要安装第三方库，通过在编译时指定编译CFLAGS即可打开开关。
使用也很简单，gcc工具链的编译选项中，
CFLAG加入选项 -fsanitize=address -fno-stack-protector -fno-omit-frame-pointer -fno-var-tracking -g1即可。
注意把libasan.so库随终端程序一块儿打包进去。libasan.so.1.0.0改名为 libasan.so.1随程序打包到lib库.
# -fsanitize=address：开启内存越界检测
# -fsanitize-recover=address：一般后台程序为保证稳定性，不能遇到错误就简单退出，而是继续运行，采用该选项支持内存出错之后程序继续运行，需要叠加设置ASAN_OPTIONS=halt_on_error=0才会生效；若未设置此选项，则内存出错即报错退出
# -fno-stack-protector：去使能栈溢出保护
# -fno-omit-frame-pointer：去使能栈溢出保护
# -fno-var-tracking：默认选项为-fvar-tracking，会导致运行非常慢
# -g1：表示最小调试信息，通常debug版本用-g即-g2
CFLAGS += -fno-stack-protector -fno-omit-frame-pointer -fno-var-tracking -g1
若出现堆栈溢出，内存溢出等问题，会立刻反应出来，如：
libasan.so库从哪获取？ 默认gcc编译器4.9版本之后自带的有啦，美吧。
从交叉工具链里找出来即可。
比如我的工具链gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.bz2
更多用法，参见：
https://blog.csdn.net/hanlizhong85/article/details/78076668
