自動附着到上SEGV和其它致命信號（panic_action）

代碼以支持一個「panic_action」最近添加到所述FreeRADIUS的爲V3.0.x，V2.0.x中和主分支處理。

當radiusd（主FreeRADIUS的處理）接收一個致命的信號（SIGFPE，SIGABRT，SIGSEGV等...），該信號處理程序執行一預定義的「panic_action」，其是傳遞給system()的殼代碼片段。信號處理程序對%e和%p執行基本替換，寫入當前二進制名稱和當前PID的值。

理論上這應該允許像gdb或lldb這樣的調試器連接到進程（panic_action = lldb -f %e -p %p），以執行交互式調試或自動收集回溯。這實際上在我的系統OSX 10.9.2上運行良好，lldb，但只適用於SIGABRT。

問題

這似乎並不爲其他信號的工作就像SIGSEGV。來自execinfo的迷你回溯有效，但當lldb或gdb附加到進程時，它們僅從信號處理程序獲得回溯。

似乎沒有辦法在lldb切換到任意的幀地址。

有誰知道是否有任何方式強制信號處理程序在與接收信號的線程相同的堆棧中執行？或者爲什麼當lldb附加後退不顯示完整的堆棧。

實際輸出看起來像：

FATAL SIGNAL: Segmentation fault: 11 
Backtrace of last 12 frames: 
0 libfreeradius-radius.dylib   0x000000010cf1f00f fr_fault + 127 
1 libsystem_platform.dylib   0x00007fff8b03e5aa _sigtramp + 26 
2 radiusd        0x000000010ce7617f do_compile_modsingle + 3103 
3 libfreeradius-server.dylib   0x000000010cef3780 fr_condition_walk + 48 
4 radiusd        0x000000010ce7710f modcall_pass2 + 191 
5 radiusd        0x000000010ce7713f modcall_pass2 + 239 
6 radiusd        0x000000010ce7078d virtual_servers_load + 685 
7 radiusd        0x000000010ce71df1 setup_modules + 1633 
8 radiusd        0x000000010ce6daae read_mainconfig + 2526 
9 radiusd        0x000000010ce78fe6 main + 1798 
10 libdyld.dylib      0x00007fff8580a5fd start + 1 
11 ???         0x0000000000000002 0x0 + 2 
Calling: lldb -f /usr/local/freeradius/sbin/radiusd -p 1397 
Current executable set to '/usr/local/freeradius/sbin/radiusd' (x86_64). 
Attaching to process with: 
    process attach -p 1397 
Process 1397 stopped 
(lldb) bt 
error: libfreeradius-radius.dylib debug map object file '/Users/arr2036/Documents/Repositories/freeradius-server-fork/build/objs//Users/arr2036/Documents/Repositories/freeradius-server-master/src/lib/debug.o' has changed (actual time is 0x530f3d21, debug map time is 0x530f37a5) since this executable was linked, file will be ignored 
* thread #1: tid = 0x8d824, 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP 
    frame #0: 0x00007fff867fee38 libsystem_kernel.dylib`wait4 + 8 
    frame #1: 0x00007fff82869090 libsystem_c.dylib`system + 425 
    frame #2: 0x000000010cf1f2e1 libfreeradius-radius.dylib`fr_fault + 849 
    frame #3: 0x00007fff8b03e5aa libsystem_platform.dylib`_sigtramp + 26 
(lldb)

代碼

和fr_set_signal()用來設置信號處理程序的功能是在這裏：https://github.com/FreeRADIUS/freeradius-server/blob/0cf0e88704228e8eac2948086e2ba2f4d17a5171/src/lib/misc.c#L61

作爲鏈接包含提交哈希代碼應該是靜態

編輯最後用版本LLDB-330.0.48上OSX 10.10.4 LLDB現在可以走過去_sigtram。

frame #2: 0x000000010b96c5f7 libfreeradius-radius.dylib`fr_fault(sig=11) + 983 at debug.c:735 
    732    FR_FAULT_LOG("Temporarily setting PR_DUMPABLE to 1"); 
    733   } 
    734 
-> 735   code = system(cmd); 
    736 
    737   /* 
    738   * We only want to error out here, if dumpable was originally disabled 
(lldb) 
frame #3: 0x00007fff8df77f1a libsystem_platform.dylib`_sigtramp + 26 
libsystem_platform.dylib`_sigtramp: 
    0x7fff8df77f1a <+26>: decl -0x16f33a50(%rip) 
    0x7fff8df77f20 <+32>: movq %rbx, %rdi 
    0x7fff8df77f23 <+35>: movl $0x1e, %esi 
    0x7fff8df77f28 <+40>: callq 0x7fff8df794d8   ; symbol stub for: __sigreturn 
(lldb) 
frame #4: 0x000000010bccb027 rlm_json.dylib`_json_map_proc_get_value(ctx=0x00007ffefa62dbe0, out=0x00007fff543534b8, request=0x00007ffefa62da30, map=0x00007ffefa62aaf0, uctx=0x00007fff54353688) + 391 at rlm_json.c:191 
    188   } 
    189   vp = map->op; 
    190 
-> 191   if (value_data_steal(vp, &vp->data, vp->da->type, value) < 0) { 
    192    REDEBUG("Copying data to attribute failed: %s", fr_strerror()); 
    193    talloc_free(vp); 
    194    goto error;

來源

2014-02-27 Arran Cudbard-Bell

這是與通過_sigtramp，在用戶進程的異步信號處理程序在回溯LLDB的錯誤。不幸的是，我不能提出解決這個問題的方法。如果您願意從源代碼構建（請參閱「源代碼」和「構建」側邊欄），它已經在lldb的樹源代碼頂部固定在http://lldb.llvm.org/。但是Xcode 5.0和下一個dot版本將會出現回溯到_sigtramp的實際問題。

來源

2014-03-01 02:45:12

只是說現在已經修復了，從xcode 6.4開始！ –

自動附着到上SEGV和其它致命信號（panic_action）

回答

相關問題