問題描述

程序kill後遲遲不退出，pstack看到一直在等鎖：

Thread 1 (Thread 0x2b3db1e9d900 (LWP 83917)):
#0  0x00002b3db6193f4d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00002b3db61915ae in _L_lock_39 () from /lib64/libpthread.so.0
#2  0x00002b3db61914e8 in [email protected]@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#3  0x00002b3dbd7a9736 in CSequenceRuntime::~CSequenceRuntime (this=0x2b3dbd9af340 <CSequenceRuntime::m_cInstance>, __in_chrg=<optimized out>) at mf_util.cpp:95
#4  0x00002b3db7aaae69 in __run_exit_handlers () from /lib64/libc.so.6
#5  0x00002b3db7aaaeb5 in exit () from /lib64/libc.so.6
#6  0x00002b3db7a93b1c in __libc_start_main () from /lib64/libc.so.6
#7  0x00000000004022b9 in _start ()
 

檢查

很明顯，在執行exit時呼叫__run_exit_handlers執行全域性變數/靜態變數的解構函式。全域性變數的解構函式中destroy一個條件變數。條件變數釋放時一直在等鎖，按理來說沒有其他執行緒拿到條件變數的鎖，而且條件變數的幾個介面pthread_cond_signal，pthread_cond_wait, pthread_cond_broast等都不會長時間拿著條件變數內部的鎖。
用gdb檢視一下pthread_cond_t的資訊(這裡只貼出來了條件變數的資料)：

m_signalCond = {__data = {__lock = 2, __futex = 2, __total_seq = 18446744073709551615, __wakeup_seq = 1, __woken_seq = 1, 
        __mutex = 0x2b65fb6eb360 <CSequenceRuntime::m_cInstance+32>, __nwaiters = 0, __broadcast_seq = 1}, 
      __size = "\002\000\000\000\002\000\000\000\377\377\377\377\377\377\377\377\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000`\263n\373e+\000\000\000\000\000\000\001\000\000", __align = 8589934594}, 
 

注意看，條件變數的__total_seq的值非常大，是uint64_t(-1)。BUG主機環境上的glibc版本是2.17，通過程式碼檢視只有在執行過pthread_cond_destroy之後才會設定為-1。這樣就有一個猜想，是不是這個條件變數已經釋放過一次，或者包含這個條件變數的物件已經釋放過一次，再進一步，就是全域性變數兩次釋放，或者有多次釋放的問題。
因為這個場景很容易重現，就用gdb跟蹤了一下，確實存在兩次釋放，而且在第二次釋放的時候會hang在這裡。
全域性變數正常情況下只會釋放一次，只有在不同的連結庫中存在相同名字的全域性物件時，才會釋放兩次。
用一個指令碼把所有的連結庫都檢查一遍，看是否有兩個連結庫包含這個全域性變數即可。pstack資訊中展示呼叫pthread_cond_destroy

for file in `ls *.so`
do 
    res=`nm $file | grep _ZN16CSequenceRuntime11m_cInstanceE`
    if [ "${res}x" != "x" ] 
    then 
        echo `ls -l $file` $res
    fi
done

_ZN16CSequenceRuntime11m_cInstanceE這個名字是我知道在哪個連結庫中包含這個符號，先用nm查出來的：

lnbillkj%nm libxxxxD.so | grep CSequenceRuntime | grep m_cInstance
000000000020f300 B _ZN16CSequenceRuntime11m_cInstanceE

通過上面的指令碼遍歷檢查，發現有個連結庫本來應該是軟連結，結果變成了真實檔案。應該是操作人員把ln命令寫成了cp。
輸出結果：

-rwxr-xr-x 1 bill aigrp 472728 Sep 26 09:26 libmdb_frame_baseD.so 000000000020f340 B _ZN16CSequenceRuntime11m_cInstanceE
-rwxr-xr-x 1 bill aigrp 3789018 Sep 26 09:26 libmdb_in_baseD.so U _ZN16CSequenceRuntime11m_cInstanceE
-rwxr-xr-x 1 bill aigrp 3789018 Sep 26 09:25 libMdbInD.so U _ZN16CSequenceRuntime11m_cInstanceE
-rwxr-xr-x 1 bill aigrp 472728 Sep 26 09:24 libMFBaseD.so 000000000020f340 B _ZN16CSequenceRuntime11m_cInstanceE

連結庫名字後面的字母U表示符號未定義，只是在連結庫中引用了，B表示符號在未初始化的資料區中(BSS)。更多資訊請看考man nm。

網上也看到兩個文章介紹全域性變數多次析構的問題，不過與本例稍有不同，可以參考漲姿勢：

1. 技巧：多共享動態庫中同名物件重複析構問題的解決方法
   這兩篇文章對全域性變數多次析構的原理進行了闡述，閱讀非常有益。第1篇文章中介紹說如果同一個實現檔案(cpp檔案)被多個連結庫編譯進去，而程式同時引用這兩個連結庫，就會出現兩個重名的全域性變數。第2篇介紹在標頭檔案中定義了全域性變數(其實大型程式中絕對不會允許這麼做)，多個連結庫引用了這個標頭檔案，而可執行程式同時引用了這些連結庫，就會出現多個同名連結庫。

另外，除了上面兩篇文章介紹的造成一個全域性符號在兩個連結庫中定義，最近還發現一個情況，就是extern Class::static_member。
比如：

/// test.h
class A
{
public:
    int a;
    static A sa; 
};

cpp實現：

test.cpp
#include "test.h"
extern A A::sa;  // 按照常規理解 extern只是變數宣告，不帶實現，然而事實並非如此

編譯：

g++ test.cpp -o libtest.so -shared -fPIC -std=c++11

檢查符號：

nm libtest.so | grep sa

輸出結果：

[~]$ nm libtest.so | grep sa
0000000000201054 B _ZN1A2saE    # B表示該符號已經定義

c++filt _ZN1A2saE 是 A::sa。
呆若木雞。