Linux系統(tǒng)開發(fā)那點(diǎn)事兒 分享經(jīng)驗得牛人力作�。ǐ@獎名單已公布-2014-5-28）

letmetryok

曾經(jīng)遇到這么一個問題：
1.在C程序中要用一個C++的庫（ICE），通過動態(tài)庫調(diào)用
2.為了能在進(jìn)程掛了后打印部分函數(shù)調(diào)用棧信息，捕獲除了SIGKILL外的進(jìn)程退出信號
3.捕獲信號后，打印函數(shù)棧到一個文件中，調(diào)用exit退出

一兩個月偶爾出現(xiàn)進(jìn)程死鎖的現(xiàn)象，通過調(diào)用strace -p發(fā)現(xiàn)進(jìn)程確實卡在了futex上，但是進(jìn)程里面找不出死鎖代碼。
最后通過gcc --pid發(fā)現(xiàn)進(jìn)程先捕獲到了退出信號，接著死鎖了。
死鎖的原因是exit內(nèi)核進(jìn)行了資源回收，調(diào)用了C++庫里面的析構(gòu)函數(shù)，析構(gòu)函數(shù)中獲取鎖導(dǎo)致死鎖。
最后找到問題代碼，最后防止出現(xiàn)類似情況使用_exit進(jìn)行暴力退出。

letmetryok

回復(fù) 11# letmetryok
寫錯了一個地方，exit的回收操作是C庫干的


   

劍魂簫心

系統(tǒng)編程初學(xué)者，
這幾天上操作系統(tǒng)原理上的比較暈，今晚繼續(xù)看Linux編程順便看懂了好幾個問題。
    隨便寫幾句。
    首先進(jìn)程和程序的區(qū)別，特南鮑姆那本操作系統(tǒng)書上有個很形象的例子，程序相當(dāng)于食譜做菜步驟，而進(jìn)程相當(dāng)于做飯的過程。也就是說進(jìn)程是一個過程，是用來執(zhí)行程序代碼的。這就有一個問題，如果一個進(jìn)程在執(zhí)行一段代碼，我想辦法把代碼給換了會怎么樣，于是就有了exec函數(shù)，這個函數(shù)可以把一個進(jìn)程所執(zhí)行的程序代碼換掉，執(zhí)行這個函數(shù)后進(jìn)程還是那個進(jìn)程，PID什么的沒變，但代碼不再是以前的代碼了，將繼續(xù)執(zhí)行新的代碼。
與此相關(guān)的fork函數(shù)，會創(chuàng)建另一個新進(jìn)程并把當(dāng)前進(jìn)程相關(guān)的環(huán)境變量、堆棧等復(fù)制一份給那個新進(jìn)程（我們將之稱為子進(jìn)程），由于這倆進(jìn)程共享一份代碼，卻有不同的內(nèi)存地址空間（包括環(huán)境變量、堆棧等數(shù)據(jù)），這樣的話，每一個進(jìn)程的堆棧是一樣的，當(dāng)前兩個進(jìn)程都在fork函數(shù)中等待返回，于是會返回兩次，雖然返回兩次但他們執(zhí)行同一份代碼，父進(jìn)程按照堆棧的指示返回fork值（子進(jìn)程ID），子進(jìn)程同樣要返回fork值（0），倆進(jìn)程在各自的進(jìn)程內(nèi)返回了自己專屬的fork返回值。于是在接下來的共享代碼中就可以用switch-case語句根據(jù)兩次返回值的不同選擇不同的代碼執(zhí)行。父進(jìn)程和子進(jìn)程里fork返回值分別為PID和0，執(zhí)行這同一段代碼到了switch-case處便會依據(jù)返回值選擇不同的分支執(zhí)行。說的略羅嗦。
    如果子進(jìn)程先掛了，那么他的進(jìn)程表項不會立即釋放，因為之后他的父進(jìn)程可能會提取一些退出信息，那么這子進(jìn)程已經(jīng)掛了，但沒釋放，就叫做僵尸進(jìn)程。等到父進(jìn)程掛了之后子進(jìn)程的進(jìn)程表項也就釋放了，如果子進(jìn)程成僵尸了，父進(jìn)程卻異常終止，那么子進(jìn)程托孤給init進(jìn)程，由他來釋放。
    如果父進(jìn)程先掛了，那么子進(jìn)程執(zhí)行完任務(wù)并掛了之后，進(jìn)程表項就立刻被釋放了。

butterfly_c

回復(fù) 3# 阿注哥


    看到thrd_cleanup（）清理函數(shù)沒有執(zhí)行，所以阻塞應(yīng)該發(fā)生在清理函數(shù)調(diào)用之前。查看pthread_cond_wait（）函數(shù)的源碼發(fā)現(xiàn)如下代碼：

1. /* Before we block we enable cancellation.  Therefore we have to
   
2.      install a cancellation handler.  */
   
3.   __pthread_cleanup_push (&buffer, __condvar_cleanup, &cbuffer);

復(fù)制代碼

也就是在自定義清理函數(shù)執(zhí)行之前，nptl先執(zhí)行__condvar_cleanup()函數(shù)，查看__condvar_cleanup()函數(shù)源碼有如下實現(xiàn)：

1. /* Get the mutex before returning unless asynchronous cancellation
   
2.      is in effect.  */
   
3.   __pthread_mutex_cond_lock (cbuffer->mutex);

復(fù)制代碼

這里應(yīng)該是造成死鎖的地方。不知與您說的是否一致？

seufy88

好活動。支持。

80520997

如何更好的組織代碼文件、什么東西單獨(dú)編譯成動態(tài)庫或靜態(tài)庫，到現(xiàn)在還沒這么弄明白

阿注哥

回復(fù) 14# butterfly_c


    兄臺高見！哈哈，我找到的也是這里。

jiejnan

      我從事服務(wù)器開發(fā)的，我遇到一個詭異問題是，自己實現(xiàn)的cache大小越大，它的性能就越差，經(jīng)過排查，cache的查找和淘汰的時間都是在合理的范圍。最后用perf 工具發(fā)現(xiàn)了內(nèi)核函數(shù)find_vma其高無比，cache大小變大（幾十G），就會導(dǎo)致find_vma占了很多cpu。
      在我們項目中，為了避開glibc自身分配和回收內(nèi)存的自身的缺陷，我們大于64k的內(nèi)存全用mmap分配，mmap分配一般不會導(dǎo)致線性區(qū)的變多，因為內(nèi)核會把相鄰的線性區(qū)盡可能合并，所以find_vma這個函數(shù)按理是不會占很多cpu。我們后來用pmap查看server，發(fā)現(xiàn)他的線性區(qū)確實異常的多。
      為什么出現(xiàn)這種情況，后來分析得出的結(jié)論是：因為cache（幾十G）中有申請內(nèi)存，也有釋放內(nèi)存，雖然我們使用了內(nèi)存池，但內(nèi)存池的空閑內(nèi)存達(dá)到一定時，也會放回glibc，所以這種情況，很有可能導(dǎo)致線性空間中的線性區(qū)不連續(xù)了，這樣內(nèi)核也就不能合并它，所以造成了find_vma異常占cpu

ls2015

支持活動   大學(xué)那會學(xué)了下Linux編程   在工作中用不到   目前已經(jīng)印象模糊了

jlyybz

linux感覺好難 反正還沒入門呢 才從開始接觸