一個無厘頭的core dump問題定位

今天收到測試部門提的一個bug，bug的內容如下：

問題現象：
suse10服務器升級到suse11 SP2後，aaasevice、loginrpc、paycenter三個網元分別發生了一次core dump

使用dmesg查看：
[166996.321057] aaaservice[30535]: segfault at 7fc667d285e2 ip 00007fc619b5ca30 sp 00007fc5defda448 error 6 in libthrift-0.8.0.so[7fc619af8000+a7000]
[175616.589046] loginrpc[30324]: segfault at 7f217e4b4fb8 ip 00007f217e24bfb8 sp 00007f2155cffb58 error 4 in libthrift-0.8.0.so[7f217e210000+a7000]
[197539.833582] paycenter[30499]: segfault at 7f415b9f3fb8 ip 00007f415b78afb8 sp 00007f41382c9768 error 4 in libthrift-0.8.0.so[7f415b74f000+a7000]

服務器從suse 10升級到suse 11 sp2後，有三個使用thrift的網元core dump了。

gdb查看core 文件，可以提供線索的信息如下：

Try: zypper install -C "debuginfo(build-id)=bddef848141961caba26bc83b17e354010ef4107"
Missing separate debuginfo for /lib64/libexpat.so.1
Try: zypper install -C "debuginfo(build-id)=2696e815e28d6ef4fcb614baf8b7802891fd5341"

warning: .dynamic section for "/usr/local/lib/libthrift-0.8.0.so" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/usr/local/lib/libactivemq-cpp.so.14" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/usr/local/lib/libapr-1.so.0" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/usr/local/lib/libaprutil-1.so.0" is not at the expected address (wrong library or version mismatch?)

用gdb查看堆棧信息，發現堆棧都是亂的，沒有任何可用的信息：

Program terminated with signal 11, Segmentation fault.
#0  0x00007f217e24bfb8 in ?? ()
(gdb) where
#0  0x00007f217e24bfb8 in ?? ()
#1  0x00007f217e276229 in ?? ()
#2  0x00007f215001cf40 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) 

查看系統core dump的日誌：

Apr 24 03:12:57 linux-h9nh kernel: [175616.589046] loginrpc[30324]: segfault at 7f217e4b4fb8 ip 00007f217e24bfb8 sp 00007f2155cffb58 error 4 in libthrift-0.8.0.so[7f217e210000+a7000]

提示都和thrift的動態庫有關係，比較測試環境和開發環境的動態庫，動態庫的版本都是一致的，開發環境運行的網元都沒有任何問題，沒有得到任何的線索。

繼續分析core dump的時間點，發現都是在4月24號發生的core dump。

在沒有任何信息的可能下，只能查看最近幾天測試人員的操作，使用history命令查看歷史記錄，還好bash的history記錄了操作的時間，然後看history裏對thrift的操作，查看的信息如下：

linux-h9nh:/usr/webtvinstall/jkh/THRIFT_INSTALL # history | grep thrift
  738  2013-04-23 09:45:13 ./thrift_install.sh
  804  2013-04-23 09:48:38 tar xvf rpm_for_activemq_and_thrift.tar.gz
  806  2013-04-23 09:48:44 cd rpm_for_activemq_and_thrift
  852  2013-04-24 06:57:37 nm /usr/local/lib/libthrift-0.8.0.so
  883  2013-04-24 03:25:43 ls -ltr *thrift*
  894  2013-04-24 05:15:48 ls -l|grep thrift
  925  2013-04-24 05:26:10 vi thrift_install.sh 

發現測試人員在4月23號的17：45分重裝了thrift。core dump都發生在重裝之後，問題和重裝有關？

於是通過日誌查看三個網元的啓動和core dump時間：

-rw-r--r-- 1 hitv hitv    3086 Apr 23 08:02 /var/log/hitv/aaaservice[13-04-23:08:03:39]
-rw-r--r-- 1 hitv hitv   45289 Apr 24 00:49 /var/log/hitv/aaaservice[13-04-24:00:49:20]

-rw-r--r-- 1 hitv hitv   1856 Apr 23 08:02 /var/log/hitv/loginrpc[13-04-23:08:03:40]
-rw-r--r-- 1 hitv hitv   2752 Apr 23 08:15 /var/log/hitv/loginrpc[13-04-24:03:13:05]

-rw-r--r-- 1 hitv hitv    7115 Apr 23 08:02 /var/log/hitv/paycenter[13-04-23:08:03:40]
-rw-r--r-- 1 hitv hitv 3365295 Apr 24 09:18 /var/log/hitv/paycenter[13-04-24:09:18:40]

發現一個共同的特點，網元都是在重裝庫之前啓動的，core dump都發生在重裝庫之後，我們的網元都是服務的進程，只有接收到消息後才進行處理，根據以往的經驗，換庫後如果不重啓網元，網元接收消息處理時會重新加載動態庫，這個時候就會發生core dump。

到此，發現問題的原因，花費1.5個小時。