? ? ? 直接運(yùn)行第九章0.2，結(jié)果一會就產(chǎn)生coredump了。時(shí)間不定。顯示簡單懷疑是否棧溢出了，通過ulimit把棧空間開大。后來又懷疑內(nèi)存太大問題，通過用-top監(jiān)控都正常。簡單的懷疑不行呀，需要用gdb調(diào)試分析了。從0.2的code學(xué)習(xí)轉(zhuǎn)為Linux下coredump分析學(xué)習(xí)，哈哈~

? ? ?? 一開始網(wǎng)上搜索了coredump出現(xiàn)的原因，我也用dmesg看了，不知道是什么意思。其實(shí)現(xiàn)在回想dmesg已經(jīng)說明了問題。

? ? ?? 后來通過gdb可以定位到是哪句c語言出錯(cuò)。是在frame初始化函數(shù)調(diào)用opencv的inline頭文件中的Mat出錯(cuò)。同時(shí)學(xué)習(xí)了如何通過gdb調(diào)試判斷棧溢出。同學(xué)們可以參考我如下blog:http://m.itdecent.cn/p/931458aac58a

? ? ?? 當(dāng)我學(xué)會了看是否棧溢出，我可以肯定的說第九章0.2沒有出現(xiàn)棧溢出。并且也發(fā)現(xiàn)了總是到一句匯編語言vmovdqa %xmm0,0x90產(chǎn)生coredump。于是去搜索vmovdqa看到一篇博文說的是cpu編譯項(xiàng)不同導(dǎo)致指令不識別而產(chǎn)生段錯(cuò)誤。我覺得我應(yīng)該也是指令無效導(dǎo)致的coredump。其實(shí)dmesg中就是這樣描述的說invalid。

問題怎么會編譯出vmodqa的呢？別人的博文說的是目標(biāo)機(jī)和編譯機(jī)器不同會產(chǎn)生問題，我就是在PC上面編譯的，運(yùn)行也是此PC，為什么呢？

接著開始發(fā)散思維了，希望能中標(biāo)。由于這部分代碼是opencv的，所以opencv一并懷疑。

我接著查的是

1. Gcc和g++的區(qū)別在我本機(jī)的區(qū)別，我本機(jī)的cpu—查了都沒有問題都是4.8.4

2. Opencv用的編譯版本，萬一我連接到了自己交叉編譯的opencv動態(tài)庫呢—查了也沒有問題

3. Opencv當(dāng)初是如何編譯的，是否有選擇machine為AMD—查了也沒有問題。

4. 自己工程的編譯選項(xiàng)有問題，包括優(yōu)化—查了果然用了-O3產(chǎn)生的問題。后來查了vmovdqa是移動對齊，自動生成的匯編一般很難保證的，怪不得掛了。

修改CmakeList.txt，刪除-march=native -O3，程序能正常執(zhí)行。花了我1周業(yè)余時(shí)間終于學(xué)會了分析coredump，并且解決了此問題。

原來MOVDQA是因?yàn)榧恿藘?yōu)化選擇項(xiàng)才產(chǎn)生了。沒有了-O3編譯選擇項(xiàng)，匯編指令都是mov。