請(qǐng)教拷貝動(dòng)態(tài)庫導(dǎo)致segmentation fault的原因

xiegang112

動(dòng)態(tài)庫是由mmap映射到進(jìn)程空間。如果在動(dòng)態(tài)庫加載后，使用諸如cp這樣的命令來替換原來的動(dòng)態(tài)庫。經(jīng)常會(huì)導(dǎo)致進(jìn)程由于segmentation fault退出。
不知道其根本原因是什么呢？
個(gè)人理解，動(dòng)態(tài)庫通過經(jīng)過mmap后，會(huì)為進(jìn)城創(chuàng)建相應(yīng)的虛擬地址空間結(jié)構(gòu)以及mapping結(jié)構(gòu)。當(dāng)進(jìn)城訪問這個(gè)動(dòng)態(tài)庫時(shí)，它被讀入內(nèi)存。由于建立mapping。它應(yīng)該進(jìn)入page cache。也就是其inode的radix tree。如果這個(gè)時(shí)候，用cp 替換改動(dòng)態(tài)庫。cp在打開文件時(shí)，內(nèi)核發(fā)現(xiàn)有系統(tǒng)中inode已經(jīng)在緩存中，因此會(huì)繼續(xù)使用這個(gè)inode（有些unix好像是重新建立inode，然后改變dentry來指向他）。這樣，新動(dòng)態(tài)庫中的內(nèi)容就會(huì)覆蓋緩存中的內(nèi)容。不過，這也僅僅是內(nèi)存覆蓋。但是為什么會(huì)造成segmentation fault呢？因?yàn)閯?dòng)態(tài)庫所在的線性地址范圍并沒有變化。

謝謝。

emmoblin

你cp覆蓋的新的so是不是有問題？
你依然還是用老的so進(jìn)行覆蓋會(huì)有問題嗎？

xiegang112

新的so應(yīng)該不會(huì)有問題，不過也說不定。我只是想看看什么導(dǎo)致了這個(gè)問題。有個(gè)鏈接說明了這個(gè)問題：
http://blog.kangkang.org/index.php/archives/49
但是沒有分析root cause。
有同樣的so覆蓋倒是沒有試過。

xiegang112

做了個(gè)實(shí)驗(yàn)，發(fā)現(xiàn)其mmap的內(nèi)存可訪問范圍會(huì)根據(jù)新的文件的大小而改變。
1)map一個(gè)8k的data文件并不斷訪問這個(gè)8k內(nèi)存區(qū)，然后用一個(gè)4k的新文來替換data文件。程序報(bào)bus error（和segment fault 一樣）。
2)而，如果是先刪掉data文件，然后把新文件cp成data文件，則程序不會(huì)出錯(cuò)。

對(duì)于1)， 當(dāng)data文件被替換時(shí)，也就是文件在寫入時(shí)，會(huì)檢查其page cache的映射。產(chǎn)生bus error，說明其文件映射變短了。
2)刪除data文件，但程序仍能讀data文件的數(shù)據(jù)，說明文件系統(tǒng)里面的inode及其page cache任然沒有被釋放。而是等程序結(jié)束后才釋放。這個(gè)應(yīng)該是其mapping或者page cache的refrence count來控制的。

so被替換而導(dǎo)致seg fault可能就是這個(gè)原因。

emmoblin

恩，總之再運(yùn)行過程中，替換so出問題是可以理解的。

xiegang112

但是，如果不是用cp，而是用mv，好像不會(huì)有問題。因?yàn)閙v是先刪除，再創(chuàng)建。這樣，兩個(gè)文件的inode不一樣。而被map的文件的inode現(xiàn)在只在內(nèi)存中存在。