跳到主要內容

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，去查閱相關文件找答案，但是這會花費一定的時間，相比之下，第二種方案肯定會更加地節約時間，但是這個方案是有條件的，條件如下： 之前的問題和當前的問題有着關聯性，換句話說，之前問題得到的答案可以幫助解決當前問題 需要記錄之前問題的答案 當然在這個例子中，可以看到的是，上面這兩個條件均滿足，大可去到之前配置過的文件中，將配置拷貝過來，然後做些細微的調整即可解決當前問題，節約了大量的時間。 不知道你是否從這些描述中發現，對於一個動態規劃問題，我們只需要從兩個方面考慮，那就是 找出問題之間的聯繫 ，以及 記錄答案 ，這裏的難點其實是找出問題之間的聯繫，記錄答案只是順帶的事情，利用一些簡單的數據結構就可以做到。 概念 上面的解釋如果大家可以理解的話，接    動態規劃 算法是通過拆分問題，定義問題狀態和狀態之間的關係，使得問題能夠以遞推（或者說分治）的方式去解決。它的幾個重要概念如下所述。    階段： 對於一個完整的問題過程，適當的切分為若干個相互聯繫的子問題，每次在求解一個子問題...
張貼留言
閱讀完整內容

我的USB為什麼總是無法識別，到底是為甚麼呢?這真的讓我好困擾

其實判斷軟件硬件問題很簡單,在別的機器或換個系統試試就可以了.有些小的問題不妨先用專門軟件格式化下.還有提醒你WINDOWS下格式化時要選擇FAT,不要選FAT32。 倘若插入後，在右下角彈出電腦正在嘗試連接此USB設備的一些信息，有時會彈出對話框讓用戶選擇，有些用戶還沒看清就點了否，或者因為電腦一些初始的設置問題，禁止了USB的一些功能。解決辦法：右鍵點"我的電腦"，選"屬性"--"硬件"--"驅動器簽名"，在此選擇"忽略"，點"確定"。然後重新插上usb，還是不連的話，再右鍵點"我的電腦"--"屬性"--"硬件"--"設備管理器"，從中找到"通用串行總線控制器"，右鍵，然後"掃描檢測硬件改動"。如果都不行那就是USB識別程序或U盤的問題從控制面板進入添加或刪除硬件將所有USB設備都刪除，重新安裝需要使用的USB設備驅動程序，重新啟動電腦 USB CONNECTOR   USB CONNECTOR  USB CONNECTOR Orignal From: 我的USB為什麼總是無法識別，到底是為甚麼呢?這真的讓我好困擾
張貼留言
閱讀完整內容

為何 Amazon 併購 Oracle 的可能性很大 ？

　　2019 年 9 月份 Trefis 團隊建議《Trefis 建議：谷歌可以斥資 90 億美元收購 Nutanix》，最近又建議亞馬遜收購 Oracle。此文是其和《福布斯》雜誌的 Great Speculations 合作撰寫。 　　根據 Trefis 分析，亞馬遜併購 Oracle 有望帶來巨大的價值。雖然這個想法聽起來很雄心勃勃，但是為了使自己處於雲技術食物鏈的頂端，Oracle 可能是亞馬遜有史以來最好的收購對象。我們詳細說明為什麼亞馬遜可能會收購 Oracle，還在交互式儀錶板中估計了潛在交易的價值。我們的估計基於 Oracle 的獨立價值以及它作為與亞馬遜合併后的實體中一部分而具有的價值。 　　 為何我們認為亞馬遜會收購 Oracle？ 　　 　　兩家公司的概況： 亞馬遜可能是在 2000 年代中期第一家打造公共雲生態系統的供應商，但 Oracle 從事數據庫業務已有近 40 年的歷史。 AWS 的想法是可以將基礎設施出租給希望存儲和計算資源方面減少費用的客戶。根據 Trefis 的估計，AWS 的企業價值高達 4930 億美元，EV/EBITDA 是 27 倍（2020 年 EBITDA 為 180 億美元）。 Oracle 因第一代雲產品失敗而很晚進入雲市場，該公司隨後在開發方面投入大量資金，旨在向市場推出第二代雲。根據 Trefis 的估計，Oracle 的企業價值應為 2510 億美元，EV/EBITDA 是 12.7 倍（2020 年 EBITDA 為 200 億美元）。 AWS 的方法是創建產品，然後讓用戶採用它。Oracle 已經長期擁有這樣的用戶群，卻無法滿足 AWS 能夠滿足的要求。結果是，儘管 Oracle 運行着全球近 50% 的數據庫，但如今 AWS 在公共雲市場的份額超過 40%，而 Oracle 甚至沒有躋身前五名。 　　理由1：客戶將獲得第二代架構的安全性和 AWS 的客戶服務，因而導致差異化產品與競爭。 由於市場上面臨微軟 Azure（已成為微軟 B2B 和 B2C 產品的底層結構）、谷歌雲（迎來新的掌門人）和 IBM 雲產品（收購 Red Hat 之後）的競爭，AWS 的先行優勢如今可能在減弱。 對老牌雲領導企業構成不利的另一個因素是，原本可以遷移到...
張貼留言
閱讀完整內容