? ? ? 直接運(yùn)行第九章0.2庇勃，結(jié)果一會(huì)就產(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://www.reibang.com/p/931458aac58a
? ? ?? 當(dāng)我學(xué)會(huì)了看是否棧溢出，我可以肯定的說第九章0.2沒有出現(xiàn)棧溢出禽绪。并且也發(fā)現(xiàn)了總是到一句匯編語言vmovdqa %xmm0,0x90產(chǎn)生coredump蓖救。于是去搜索vmovdqa看到一篇博文說的是cpu編譯項(xiàng)不同導(dǎo)致指令不識(shí)別而產(chǎn)生段錯(cuò)誤。我覺得我應(yīng)該也是指令無效導(dǎo)致的coredump印屁。其實(shí)dmesg中就是這樣描述的說invalid循捺。
問題怎么會(huì)編譯出vmodqa的呢？別人的博文說的是目標(biāo)機(jī)和編譯機(jī)器不同會(huì)產(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動(dòng)態(tài)庫呢—查了也沒有問題
3. Opencv當(dāng)初是如何編譯的驻民，是否有選擇machine為AMD—查了也沒有問題翻具。
4. 自己工程的編譯選項(xiàng)有問題，包括優(yōu)化—查了果然用了-O3產(chǎn)生的問題回还。后來查了vmovdqa是移動(dòng)對(duì)齊裆泳，自動(dòng)生成的匯編一般很難保證的，怪不得掛了柠硕。
修改CmakeList.txt工禾，刪除-march=native -O3，程序能正常執(zhí)行蝗柔。花了我1周業(yè)余時(shí)間終于學(xué)會(huì)了分析coredump闻葵，并且解決了此問題。
原來MOVDQA是因?yàn)榧恿藘?yōu)化選擇項(xiàng)才產(chǎn)生了癣丧。沒有了-O3編譯選擇項(xiàng)槽畔，匯編指令都是mov。
