请教拷贝动态库导致segmentation fault的原因

xiegang112

动态库是由mmap映射到进程空间。如果在动态库加载后，使用诸如cp这样的命令来替换原来的动态库。经常会导致进程由于segmentation fault退出。
不知道其根本原因是什么呢？
个人理解，动态库通过经过mmap后，会为进城创建相应的虚拟地址空间结构以及mapping结构。当进城访问这个动态库时，它被读入内存。由于建立mapping。它应该进入page cache。也就是其inode的radix tree。如果这个时候，用cp 替换改动态库。cp在打开文件时，内核发现有系统中inode已经在缓存中，因此会继续使用这个inode（有些unix好像是重新建立inode，然后改变dentry来指向他）。这样，新动态库中的内容就会覆盖缓存中的内容。不过，这也仅仅是内存覆盖。但是为什么会造成segmentation fault呢？因为动态库所在的线性地址范围并没有变化。

谢谢。

emmoblin

你cp覆盖的新的so是不是有问题？
你依然还是用老的so进行覆盖会有问题吗？

xiegang112

新的so应该不会有问题，不过也说不定。我只是想看看什么导致了这个问题。有个链接说明了这个问题：
http://blog.kangkang.org/index.php/archives/49
但是没有分析root cause。
有同样的so覆盖倒是没有试过。

xiegang112

做了个实验，发现其mmap的内存可访问范围会根据新的文件的大小而改变。
1)map一个8k的data文件并不断访问这个8k内存区，然后用一个4k的新文来替换data文件。程序报bus error（和segment fault 一样）。
2)而，如果是先删掉data文件，然后把新文件cp成data文件，则程序不会出错。

对于1)， 当data文件被替换时，也就是文件在写入时，会检查其page cache的映射。产生bus error，说明其文件映射变短了。
2)删除data文件，但程序仍能读data文件的数据，说明文件系统里面的inode及其page cache任然没有被释放。而是等程序结束后才释放。这个应该是其mapping或者page cache的refrence count来控制的。

so被替换而导致seg fault可能就是这个原因。

emmoblin

恩，总之再运行过程中，替换so出问题是可以理解的。

xiegang112

但是，如果不是用cp，而是用mv，好像不会有问题。因为mv是先删除，再创建。这样，两个文件的inode不一样。而被map的文件的inode现在只在内存中存在。