問題：

工作中，我們在varnish的基礎上，利用vmod機制，實現了一個可以定製策略，且策略可自動載入而不需重新啟動引擎的cache（平時，大家對varnish的利用，cache策略都定義在一個vcl配置檔案中，每次對策略進行修改，都需要重新啟動varnish，從而使得策略生效，且當部署在varnish後面的站點很多時，不方便對每站點的cache策略進行個性化的定製），這裡各種策略的控制以及載入都實現在一個vmod模組裡（libvmod_ngcache.so）,很開心，產品上線了。那麼問題來，（挖掘機技術那家強？）當程式上到線上的時候，有時會出現各種bug,尤其是當程式崩潰了，而又沒有對相應的core dump資訊進行儲存的時候，怎麼定位問題出在程式的哪個位置就成為了一個難題

解決方法：

程式發生段錯誤時，提示資訊很少，在沒有儲存相應的core dump資訊的情況下，要對這類錯誤進行除錯尤為顯得捉襟見肘，幸運的是我們可以利用linux系統自帶的一些小工具來檢視段錯誤發生的各種資訊：

dmesg 可以在應用程式崩潰的時候，顯示核心中儲存的相關資訊：

[email protected]****:/home/l7# dmesg-T | grep varnishd

[Thu Dec  421:25:58 2014] varnishd[16470] general protection ip:7feb693443bbsp:7feb669ea1e0 error:0 in libvmod_ngcache.so.1.0.0[7feb69331000+52000]

有時候，通過檢視相應的核心日誌，也可以檢視到同樣的資訊：

[email protected]****:/home/l7# cat/var/log/kern.log

Dec  5 07:49:34 ****kernel: [17376990.017811] varnishd[16470] general protection ip:7feb693443bbsp:7feb669ea1e0 error:0 in libvmod_ngcache.so.1.0.0[7feb69331000+52000]

[email protected]****:/home/l7# dmesg| grep varnishd

[17376990.017811] varnishd[16470] general protectionip:7feb693443bb sp:7feb669ea1e0 error:0 inlibvmod_ngcache.so.1.0.0[7feb69331000+52000]

輸出資訊內容：段錯誤發生的時間（[17376990.017811]）、發生段錯誤的程式名稱[程序號]（varnishd[16470]）、引起段錯誤發生的指令指標地址（general protection ip:7feb693443bb）、引起段錯誤發生的堆疊指標地址（sp:7feb669ea1e0）、錯誤程式碼（error:0）、libvmod_ngcache.so.1.0.0[7feb69331000+52000]（In the libfoo.so[NNNNNN+YYYY] part, the NNNNNN is where the librarywas loaded. Subtract this from theinstruction pointer (ip) and you'll getthe offset into the .so of the offendinginstruction. Then you can use objdump -DCgl libfoo.so andsearch for the instruction at that offset. You should easily be able to figureout which function it is from the asm labels.If the .so doesn't haveoptimizations you can also try using addr2line-e libfoo.so <offset>, 52000 = 0xcb20）。

因此，有動作：

(一)：

ip:0x7feb693443bb -libvmod_ngcache.so.1.0.0[0x7feb69331000+YYYY] = 0x133bb

[email protected]****:/home/l7# objdump-DCgl /usr/local/lib/varnish/vmods/libvmod_ngcache.so | grep -C 10 133bb

   1339c: 0f b6 c2               movzbl%dl,%eax

   1339f: 48 8b 5c c1 08         mov    0x8(%rcx,%rax,8),%rbx

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:864

   133a4: 48 85 db               test   %rbx,%rbx

   133a7: 74 1f                  je     133c8<KTrieSearch+0x1b8>

   133a9: 44 8b 6c 24 2c         mov    0x2c(%rsp),%r13d

   133ae: 4c 89 fd               mov    %r15,%rbp

   133b1: 0f 1f 80 00 00 00 00   nopl   0x0(%rax)

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:868

   133b8: 0f b6 c2               movzbl%dl,%eax

   133bb: 39 03                  cmp    %eax,(%rbx)

   133bd: 74 71                  je     13430 <KTrieSearch+0x220>

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:895

   133bf: 48 8b 5b 08            mov    0x8(%rbx),%rbx

   133c3: 48 85 db               test   %rbx,%rbx

   133c6: 75 f0                  jne    133b8<KTrieSearch+0x1a8>

KTrieSearchNoBC():

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:979

   133c8: 44 01 74 24 30         add    %r14d,0x30(%rsp)

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:977

   133cd: 49 83 c7 01            add    $0x1,%r15

這裡基本上可以定位到出問題的函數了。

（二）：

ip:0x7feb693443bb -libvmod_ngcache.so.1.0.0[0x7feb69331000+YYYY] = 0x133bb

[email protected]****:/home/l7# addr2line-e /usr/local/lib/varnish/vmods/libvmod_ngcache.so 0x133bb -f

KTriePrefixMatch

/var/lib/jenkins/workspace/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/l7cache_ngcache_vmod_for_varnish3.0.5_First_Edition/varnish_vmod/libvmod-ngcache/src/sfksearch.c:868

（三）：

ip:0x7feb693443bb -libvmod_ngcache.so.1.0.0[0x7feb69331000+YYYY] = 0x133bb

[email protected]****:/home/l7# gdb/usr/local/lib/varnish/vmods/libvmod_ngcache.so

......

(gdb) disass0x133bb

......

  0x0000000000013399 <+393>:    xor    %r14d,%r14d

  0x000000000001339c <+396>:    movzbl%dl,%eax

  0x000000000001339f <+399>:    mov    0x8(%rcx,%rax,8),%rbx

  0x00000000000133a4 <+404>:    test   %rbx,%rbx

  0x00000000000133a7 <+407>:    je     0x133c8 <KTrieSearch+440>

  0x00000000000133a9 <+409>:    mov    0x2c(%rsp),%r13d

  0x00000000000133ae <+414>:    mov    %r15,%rbp

  0x00000000000133b1 <+417>:    nopl   0x0(%rax)

  0x00000000000133b8 <+424>:    movzbl%dl,%eax

   0x00000000000133bb <+427>:   cmp   %eax,(%rbx)

  0x00000000000133bd <+429>:    je     0x13430 <KTrieSearch+544>

  0x00000000000133bf <+431>:    mov    0x8(%rbx),%rbx

  0x00000000000133c3 <+435>:    test   %rbx,%rbx

  0x00000000000133c6 <+438>:    jne    0x133b8 <KTrieSearch+424>

另：推薦一些工具，供大家學習使用：

gdb、ldd、eu-readelf、readelf、objdump、dmesg、addr2line、nm、catchsegv；

另外建議，像這種線上的程式，儘量配置當程式crash的時候有coredump檔案產生或者記錄stack backtrace。

問題的查詢，參考了網路上很多的文章和Q&A，在這裡表示感謝並列出原文引用，謝謝！

Refer：

1、"Linux環境下段錯誤的產生原因及除錯方法小結"

2、"How doyou read a segfault kernel log message"

3、"DebuggingC++ (Part 3): dmesg"

4、"Introductionto segmentation fault handling"

5、"Pythoncrashed; how to decode segfault in dmesg log?"