跳到主要內容

Dev 日誌 | 一次 Segmentation Fault 和 GCC Illegal Instruction 編譯問題排查


摘要


筆者最近在重新整理和編譯 Nebula Graph 的第三方依賴，選出兩個比較有意思的問題給大家分享一下。


Flex Segmentation Fault——Segmentation fault (core dumped)


在編譯 Flex 過程中，遇到了 Segmentation fault：


make[2]: Entering directory '/home/dutor/flex-2.6.4/src'
 ./stage1flex   -o stage1scan.c ./scan.l
 make[2]: *** [Makefile:1696: stage1scan.c] Segmentation fault (core dumped)

使用 gdb 查看 coredump：


Core was generated by `./stage1flex -o stage1scan.c ./scan.l'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  flexinit (argc=4, argv=0x7ffd25bea718) at main.c:976
 976             action_array[0] = '\0';
 (gdb) disas
 Dump of assembler code for function flexinit:
    0x0000556c1b1ae040 <+0>:     push   %r15
    0x0000556c1b1ae042 <+2>:     lea    0x140fd(%rip),%rax        # 0x556c1b1c2146
    ...
    0x0000556c1b1ae20f <+463>:   callq  0x556c1b1af460 <allocate_array> #這裏申請了buffer
    ...
 => 0x0000556c1b1ae24f <+527>:   movb   $0x0,(%rax) # 這裏向buffer[0]寫入一個字節，地址非法，掛掉了
    ...
 (gdb) disas allocate_array
 Dump of assembler code for function allocate_array:
    0x0000556c1b1af460 <+0>:     sub    $0x8,%rsp
    0x0000556c1b1af464 <+4>:     mov    %rsi,%rdx
    0x0000556c1b1af467 <+7>:     xor    %eax,%eax
    0x0000556c1b1af469 <+9>:     movslq %edi,%rsi
    0x0000556c1b1af46c <+12>:    xor    %edi,%edi
    0x0000556c1b1af46e <+14>:    callq  0x556c1b19a100 <reallocarray@plt> # 調用庫函數申請內存
    0x0000556c1b1af473 <+19>:    test   %eax,%eax # 判斷是否為 NULL
    0x0000556c1b1af475 <+21>:    je     0x556c1b1af47e <allocate_array+30># 跳轉至NULL錯誤處理
    0x0000556c1b1af477 <+23>:    cltq   # 將 eax 符號擴展至 rax，造成截斷
    0x0000556c1b1af479 <+25>:    add    $0x8,%rsp
    0x0000556c1b1af47d <+29>:    retq
    ...
 End of assembler dump.

可以看到，問題出在了 allocate_array 函數。因為 reallocarray 返回指針，返回值應該使用 64 bit 寄存器rax，但 allocate_array 調用 reallocarray 之後，檢查的卻是 32 bit 的 eax，同時使用 cltq 指令將 eax 符號擴展 到 rax。原因只有一個：allocate_array 看到的 reallocarray 的原型，與 reallocarry 的實際定義不符。翻看編譯日誌，確實找到了 implicit declaration of function 'reallocarray' 相關的警告。configure 階段添加 CFLAGS=-D_GNU_SOURCE 即可解決此問題。


注：此問題不是必現，但編譯/鏈接選項 -pie 和 內核參數 kernel.randomize_va_space 有助於復現。


總結：



  • 隱式聲明的函數在 C 中，返回值被認為是 int。

  • 關注編譯器告警，-Wall -Wextra 要打開，開發模式下最好打開 -Werror。


GCC Illegal Instruction——internal compiler error: Illegal instruction


前陣子，接到用戶反饋，在編譯 Nebula Graph 過程中遭遇了編譯器非法指令的錯誤，詳見(#978)[]


錯誤信息大概是這樣的：


Scanning dependencies of target base_obj_gch
 [ 0%] Generating Base.h.gch
 In file included from /opt/nebula/gcc/include/c++/8.2.0/chrono:40,
 from /opt/nebula/gcc/include/c++/8.2.0/thread:38,
 from /home/zkzy/nebula/nebula/src/common/base/Base.h:15:
 /opt/nebula/gcc/include/c++/8.2.0/limits:1599:7: internal compiler error: Illegal instruction
 min() _GLIBCXX_USE_NOEXCEPT { return FLT_MIN; }
 ^~~
 0xb48c5f crash_signal
 ../.././gcc/toplev.c:325
 Please submit a full bug report,
 with preprocessed source if appropriate.

既然是 internal compiler error，想必是 g++ 本身使用了非法指令。為了定位具體的非法指令集及其所屬模塊，我們需要復現這個問題。幸運的是，下面的代碼片段就能觸發：


#include <thread>
 int main() 
 {
     return 0;
 }

非法指令一定會觸發 SIGILL，又因為 g++ 只是編譯器的入口，真正幹活的是 cc1plus。我們可以使用 gdb 來運行編譯命令，抓住子進程使用非法指令的第一現場：


$ gdb --args /opt/nebula/gcc/bin/g++ test.cpp
 gdb> set follow-fork-mode child
 gdb> run
 Starting program: /opt/nebula/gcc/bin/g++ test.cpp
 [New process 31172]
 process 31172 is executing new program: /opt/nebula/gcc/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1plus
 Thread 2.1 "cc1plus" received signal SIGILL, Illegal instruction.
 [Switching to process 31172]
 0x00000000013aa0fb in __gmpn_mul_1 ()
 gdb> disas
 ...
 0x00000000013aa086 <+38>: mulx (%rsi),%r10,%r8
 ...

Bingo！mulx 屬於 BMI2 指令集，報錯機器 CPU 不支持該指令集。
仔細調查，引入該指令集的是 GCC 的依賴之一，GMP。默認情況下，GMP 會在 configure 階段探測當前機器的 CPU 具體類型，以期最大化利用 CPU 的擴展指令集，提升性能，但卻犧牲了二進制的可移植性。解決方法是，在 configure 之前，使用代碼目錄中的 configfsf.guess configfsf.sub 替換或者覆蓋默認的 config.guess 和 config.sub


總結：



  • 某些依賴可能因為性能或者配置的原因，造成二進制的不兼容。

  • 缺省參數下，GCC 為了兼容性，不會使用較新的指令集。

  • 為了平衡兼容性和性能，你需要做一些額外的工作，比如像 glibc 那樣在運行時選擇和綁定某個具體實現。


最後，如果你想嘗試編譯一下 Nebula 源代碼可參考以下方式：


bash> git clone https://github.com/vesoft-inc/nebula.git
 bash> cd nebula && ./build_dep.sh N

有問題請在 GitHub 或者微信公眾號上留言。


附錄



  • Nebula Graph：一個開源的分佈式圖數據庫

  • GitHub：

  • 知乎：

  • 微博：


本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計



※不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務



※Google地圖已可更新顯示潭子電動車充電站設置地點!!



※帶您來看台北網站建置，台北網頁設計，各種案例分享



※小三通物流營運型態?



※快速運回,大陸空運推薦?



Orignal From: Dev 日誌 | 一次 Segmentation Fault 和 GCC Illegal Instruction 編譯問題排查

留言

張貼留言

這個網誌中的熱門文章

有了四步解題法模板，再也不害怕動態規劃！（看不懂算我輸）

導言 動態規劃問題一直是算法面試當中的重點和難點，並且動態規劃這種通過空間換取時間的算法思想在實際的工作中也會被頻繁用到，這篇文章的目的主要是解釋清楚 什麼是動態規劃 ，還有就是面對一道動態規劃問題，一般的 思考步驟 以及其中的注意事項等等，最後通過幾道題目將理論和實踐結合。 什麼是動態規劃 如果你還沒有聽說過動態規劃，或者僅僅只有耳聞，或許你可以看看 Quora 上面的這個 回答 。 How to explain dynamic 用一句話解釋動態規劃就是 " 記住你之前做過的事 "，如果更準確些，其實是 " 記住你之前得到的答案 "。 我舉個大家工作中經常遇到的例子。 在軟件開發中，大家經常會遇到一些系統配置的問題，配置不對，系統就會報錯，這個時候一般都會去 Google 或者是查閱相關的文檔，花了一定的時間將配置修改好。 過了一段時間，去到另一個系統，遇到類似的問題，這個時候已經記不清之前修改過的配置文件長什麼樣，這個時候有兩種方案，一種方案還是去 Google 或者查閱文檔，另一種方案是借鑒之前修改過的配置，第一種做法其實是萬金油，因為你遇到的任何問題其實都可以去 Google，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

計算機本地文件快要滅絕了

　　 編者按： 文件是数字世界的基石，是我們基本的工作單位。但是，隨着互聯網的雲化、平台化、服務化，文件日益變得可有可無。這樣一種改變究竟好不好呢？喜歡懷舊的 Simon Pitt 開始回顧各種文件的好處，哪怕這讓他顯得不合時宜。原文發表在 medium 上，標題是：Computer Files Are Going Extinct 　　我喜歡文件。我喜歡對文件重命名、移動、排序，改變它們在文件夾中的显示方式，去備份文件，將之上傳到互聯網，恢復它們，對其進行複製，甚至還可以對文件進行碎片整理。作為信息存儲方式的一種隱喻，在我看來文件是很出色的。我喜歡把文件當作一個工作單位。如果我要寫篇文章，文章會放在文件裏面。如果我要生成圖像，圖像會保存進文件裏面。 　　 謳歌 files.doc 　　文件是擬物化的。這是個很花哨的詞，只是用來表示文件是反映現實物品的一個数字概念。比方說，Word 文檔就像一張紙，躺在你的辦公桌上（desktop）。JPEG 就像一幅畫，等等。它們每個都有一個小圖標，圖標的樣子看起來像它們所代表的現實物品。一堆紙，一個畫框，一個馬尼拉文件夾。真的挺很迷人的。 　　我喜歡文件的一點是，不管裏面有什麼，跟文件的交互方式總是一致的。我上面提到的那些東西——複製、排序、碎片整理——我可以對任何文件進行那些處理。文件可能是圖像、遊戲的一部分、也可能是我最喜歡的餐具清單。碎片整理程序不在乎它是什麼。它不會去判斷內容。 　　自從我開始在 Windows 95 裏面創建文件以來，我就一直都很喜歡文件。但是我注意到我們已經開始慢慢地遠離把文件當作基本工作單位的做法。 Windows95。我的計算機 　　 services.mp3 的興起 　　十幾歲的時候，我開始痴迷於收集和管理数字音樂：我收藏 MP3 文件。一大堆的 128 kbps MP3 文件。如果你足夠幸運，有自己的 CD 刻錄機的話，就可以將它們刻錄到 CD 上，然後在朋友之間傳遞。一張 CD 可以容納 700 MB。這相當於將近 500 張軟盤！ 　　我會仔細端詳我的收藏，然後煞費苦心地給它們添加上 IDv1 和 IDv2 音樂標籤。隨着時間的流逝，大家開始開發可以在雲端自動獲取曲目列表的工具，這樣你就可以檢查和驗證 MP3 的質量。有時候我甚至會去聽那些該死的東西，儘管...
張貼留言
閱讀完整內容

純電動 Mini Cooper SE 將成為中國國產車，年產 16 萬輛

BMW 集團與中國長城汽車合資，將於江蘇建立新廠，專門投入生產 MINI Cooper SE 和部分長城品牌電動車，預計於 2022 年完工並投入生產，每年將可生產 16 萬輛電動車。 靈動可愛的 Mini Cooper，在許多車迷心中都有著特殊的地位，今年 7 月發表了首款純電動版本的 Mini Cooper SE 之後，獲得熱烈迴響，預訂數量已接近 8 萬台，顯示大家對於純電 Mini 的熱愛，因為油電版的 Mini Cooper Countryman 的全球總銷售量也才 3 萬出頭。 Mini Cooper SE 之前公布了官方定價，最低從 27,900 歐元起算，美國售價約 29,900 美元。相比現有的三門款，只貴了一成左右。然而，三年後，中國消費者將有機會買到最便宜的電動 Mini。 電動 Mini Cooper SE 最低價是 27,900 歐元，扣掉全額補助最低可以到 24,400 歐元。 BMW 集團與中國長城汽車集團於 2018 年宣布，將組建合資公司光束汽車，投入在中國的電動車生產計畫，而現在他們正式宣布啟動計畫，於江蘇張家港打造一個新工廠，全部投入電動車的製造，包括了 Mini Cooper SE 和其他長城汽車旗下的電動車。 目前的電動 Mini 只在英國牛津工廠製造，不難想像當產能轉移到中國後，Mini Cooper SE 的價格將有機會進一步調降，來競爭全球最大的電動車市場。這座屬於合資公司光束汽車的新工廠，採用一個新的產銷模式，由 BMW 和長城共同合作開發、設計、製造新產品，但是銷售通路完全沿用原本的品牌渠道。 換句話說，2020 年到 2022 年銷售的電動 Mini，將會是英國製造，而 2022 年後就會有中國製造版本開賣，考量到 Mini 在中國每年約有 30 萬輛的銷售額，同時油電版的 Coutryman 銷量更佔了全球將近五分之一，無怪乎 BMW 會想在最接近主要市場的地方蓋工廠囉。 外型完美復刻油車版 最後，簡單介紹一下 Mini Cooper SE 這台車。Mini 在電動化的路上，盡力保持著跟經典造型一致的設計，畢竟大家愛的就是它的設計。電動版的 Mini 車頭、車身跟車屁股都多了一個黃色的插頭標誌，車頭的氣壩則變成封閉式設計，除此之外，幾乎看不出來差別，連馬達...
張貼留言
閱讀完整內容