ARM平臺上的SIGABRT信號沒有回溯？

Question

我在信號處理程序中使用'backtrce（）'和'backtrace_symbols_fd（）'函數來生成調試回溯（GDB不可用）。

他們工作的x86桌面（Ubuntu的）的罰款，但目標設備（基於ARM）的中止信號回溯（由於雙免費誤差）上僅顯示三個幀：信號處理器和兩個從內libc，這對調試我們的代碼沒有用處！在SEGV上追蹤（例如，使用一個不好的指針）會產生一個好的回溯。

爲什麼我無法在ARM上的ABRT信號上獲得有用的回溯？

[提問編輯爲清晰起見]

下面是這表明了問題的一個簡單的測試程序：

#include <execinfo.h> 
#include <signal.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <unistd.h> 

// Signal hangler to catch seg fault: 
void handler_segv(int sig) { 
    // get void*'s for all entries on the stack 
    void *array[10]; 
    size_t size; 
    size = backtrace(array, 10); 
    fprintf(stderr, "Error: Signal %d; %d frames found:\n", sig, size); 
    // print out all the frames to stderr 
    backtrace_symbols_fd(array, size, STDERR_FILENO); 
    exit(1); 
} 


void crashme() 
{ 
    // Deliberate Error: Abort (double free): 
    char *test_ptr = malloc(1); 
    free(test_ptr); 
    free(test_ptr); 
    // Deliberate Error #2: Seg fault: 
    //char * p = NULL; 
    //*p = 0; 
} 

void foo() 
{ 
    fprintf(stdout, "---->About to crash...\n"); 
    crashme(); 
    fprintf(stdout, "---->Crashed (shouldn't get to here)...\n"); 
} 



// Main entry point: 
int main(int argc, char *argv[]) 
{ 
    fprintf(stdout, "Application start...\n"); 

    // Install signal handlers: 
    fprintf(stdout, "-->Adding handler for SIGSEGV and SIGABRT\n"); 
    signal(SIGSEGV, handler_segv); 
    signal(SIGABRT, handler_segv); 

    fprintf(stdout, "-->OK. Causing Error...\n"); 
    foo(); 
    fprintf(stdout, "-->Test finished (shouldn't get to here!)\n"); 
    return 0; 
} 

這被編譯爲x86架構如下：

gcc -o test test-backtrace-simple.c -g -rdynamic 

而對於ARM：

arm-none-linux-gnueabi-gcc -o test-arm test-backtrace-simple.c -g -rdynamic -O0 -mapcs-frame -funwind-tables -fasynchronous-unwind-tables 

我已經使用ARM的各種編譯器選項，如其他與ARM上生成回溯相關的帖子中所述。

當在x86桌面上運行，它會生成用大量調試的預期輸出，在結束：

Error: Signal 6; 10 frames found: 
./test(handler_segv+0x19)[0x80487dd] 
[0xb7745404] 
[0xb7745428] 
/lib/i386-linux-gnu/libc.so.6(gsignal+0x4f)[0xb75b0e0f] 
/lib/i386-linux-gnu/libc.so.6(abort+0x175)[0xb75b4455] 
/lib/i386-linux-gnu/libc.so.6(+0x6a43a)[0xb75ed43a] 
/lib/i386-linux-gnu/libc.so.6(+0x74f82)[0xb75f7f82] 
./test(crashme+0x2b)[0x8048855] 
./test(foo+0x33)[0x804888a] 
./test(main+0xae)[0x8048962] 

（即，通過我的處理程序產生的，與我的功能在底部調用回溯）。

然而，在ARM平臺上運行，我得到：

Application start... 
-->Adding handler for SIGSEGV and SIGABRT 
-->OK. Causing Error... 
---->About to crash... 
*** Error in `/opt/bin/test-arm': double free or corruption (fasttop): 0x015b6008 *** 
Error: Signal 6; 3 frames found: 
/opt/bin/test-arm(handler_segv+0x24)[0x8868] 
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0xb6e6c150] 
/lib/libc.so.6(gsignal+0x34)[0xb6e6af48] 

回溯（）只找到3張，他們只是在信號處理程序，並在libc中的東西（沒有用）！

我發現了一個郵件列表帖子裏面說：

If you link with the debugging C library, -lc_g, you'll get debugging info back past abort().

這可能是相關的，但-lc_g不會對我的編譯器（LD：找不到-lg_c）工作。

回溯工作正常上ARM如果我生成賽格故障代替（例如變化crashme（）函數的使用 「的char * p值= NULL; * p值= 0;」。而不是雙自由

不限想法或建議其他方式獲得回溯？

[ - 編輯]

我嘗試了一些MALLOC_CHECK_選項在評論中建議，但唯一的作用就是改變是否發生中止。這是ARM上三次運行的輸出：

# MALLOC_CHECK_=0 /opt/bin/test-arm 
Application start... 
-->Adding handler for SIGSEGV and SIGABRT 
-->OK. Causing Error... 
---->About to crash... 
---->Crashed (shouldn't get to here)... 
-->Test finished (shouldn't get to here!) 


# MALLOC_CHECK_=1 /opt/bin/test-arm 
Application start... 
-->Adding handler for SIGSEGV and SIGABRT 
-->OK. Causing Error... 
---->About to crash... 
*** Error in `/opt/bin/test-arm': free(): invalid pointer: 0x015b2008 *** 
---->Crashed (shouldn't get to here)... 
-->Test finished (shouldn't get to here!) 


# MALLOC_CHECK_=2 /opt/bin/test-arm 
Application start... 
-->Adding handler for SIGSEGV and SIGABRT 
-->OK. Causing Error... 
---->About to crash... 
Error: Signal 6; 3 frames found: 
/opt/bin/test-arm(handler_segv+0x24)[0x8868] 
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0xb6e24150] 
/lib/libc.so.6(gsignal+0x34)[0xb6e22f48] 
# 

MALLOC_CHECK_ = 0：沒有錯誤信息（雙倍空閒被忽略！）

MALLOC_CHECK_ = 1：錯誤消息，但程序繼續

MALLOC_CHECK_ = 2：錯誤消息，並且ABRT信號;產生無用的回溯（這是默認的行爲！）

我的交叉編譯報道： gcc版本4.6.1（的Sourcery Codebench完成精簡版2011.09-70） 目標設備的Linux內核版本3.8.8

Answer 1

我有同樣的問題。我嘗試了內置的backtrace_symbols（）方法，發現它偶爾可以工作，但大多停在信號處理程序中。然後我嘗試了backward.hpp和deathhandler，得到了類似的結果。

libubwind v1.2rc正在爲SIGSEGV，SIGABRT使用我自己的信號處理程序（裏面沒有特別的代碼，只是從libunwind請求回溯）。試一試。

Answer 2

看來您已經做了充分的研究，以瞭解在編譯器命令行中需要開關-funwind-tables和-fasynchronous-unwind-tables。在實踐中，他們中的任何一個似乎都是足夠的，但顯然沒有他們回溯根本不起作用。現在，像SIGABRT這樣的問題是，回溯必須遍歷由libc函數（例如abort和gsignal）生成的堆棧幀，並且因爲該lib不是使用其中任何一個開關構建的（在我知道的任何分佈中） 。

儘管向Sourcery CodeBench的維護者請求使用該選項構建它們的發行版本是很好的，但唯一的即時解決方案是自己構建libc，並設置其中一個或兩個標誌（根據我的經驗，只需-funwind-tables就足夠了）。如果在捕獲未處理的異常（通過std::set_terminate）的情況下還需要堆棧跟蹤，則還需要重新構建libstdC++。

在我的工作場所，我們需要對兩種情況（SIGABRT和未處理的異常）進行回溯，並且由於libstdC++是工具鏈的一部分，所以我們自己重新構建了工具鏈。該工具crosstool-NG使這相對容易做到。在配置實用程序./ct-ng menuconfig中，我們輸入了部分Target Options並編輯了Target CFLAGS（它將生成變量TARGET_CFLAGS）設置爲-funwind-tables。由此產生的工具鏈（更具體地說，使用生成的工具鏈構建中的libc和libstdC++）爲我們提供了所有情況下的完整回溯。