直接运行第九章0.2，结果一会就产生coredump了。时间不定。显示简单怀疑是否栈溢出了，通过ulimit把栈空间开大。后来又怀疑内存太大问题，通过用-top监控都正常。简单的怀疑不行呀，需要用gdb调试分析了。从0.2的code学习转为Linux下coredump分析学习，哈哈~
一开始网上搜索了coredump出现的原因，我也用dmesg看了，不知道是什么意思。其实现在回想dmesg已经说明了问题。
后来通过gdb可以定位到是哪句c语言出错。是在frame初始化函数调用opencv的inline头文件中的Mat出错。同时学习了如何通过gdb调试判断栈溢出。同学们可以参考我如下blog:https://www.jianshu.com/p/931458aac58a
当我学会了看是否栈溢出，我可以肯定的说第九章0.2没有出现栈溢出。并且也发现了总是到一句汇编语言vmovdqa %xmm0,0x90产生coredump。于是去搜索vmovdqa看到一篇博文说的是cpu编译项不同导致指令不识别而产生段错误。我觉得我应该也是指令无效导致的coredump。其实dmesg中就是这样描述的说invalid。
问题怎么会编译出vmodqa的呢？别人的博文说的是目标机和编译机器不同会产生问题，我就是在PC上面编译的，运行也是此PC，为什么呢？
接着开始发散思维了，希望能中标。由于这部分代码是opencv的，所以opencv一并怀疑。
我接着查的是
1. Gcc和g++的区别在我本机的区别，我本机的cpu—查了都没有问题都是4.8.4
2. Opencv用的编译版本，万一我连接到了自己交叉编译的opencv动态库呢—查了也没有问题
3. Opencv当初是如何编译的，是否有选择machine为AMD—查了也没有问题。
4. 自己工程的编译选项有问题，包括优化—查了果然用了-O3产生的问题。后来查了vmovdqa是移动对齐，自动生成的汇编一般很难保证的，怪不得挂了。
修改CmakeList.txt，删除-march=native -O3，程序能正常执行。花了我1周业余时间终于学会了分析coredump，并且解决了此问题。
原来MOVDQA是因为加了优化选择项才产生了。没有了-O3编译选择项，汇编指令都是mov。
