关于so文件cp覆盖导致调用者core的研究
先说cp好mv/rm的区别:
cp from to,则被覆盖文件 to的inode依旧不变(属性也不变),内容变为from的;
mv from to,则to的inode变为from的,相应的,to的属性也成了from的;rm类似;
问题,假如程序 main.out依赖的so文件libtest.so被cp掉,会发生什么?
strace cp test2 test 2>&1 | grep open.*test open("test2", O_RDONLY|O_LARGEFILE) = 3 open("test", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4
cp的实现逻辑不是“rm + open(O_CREAT)”,而上面的实现方式才是最可靠的(保证了时序安全和目标文件的属性)。这解释了为什么cp的目标文件会继承被覆盖文件的属性而非源文件。
Linux由于Demand Paging机制的关系,必须确保正在运行中的程序镜像(注意,并非文件本身)不被意外修改,因此内核在启动程序后会绑定 内存页 到这个so的inode,而一旦此inode文件被open函数O_TRUNC掉,则kernel会把so文件对应在虚存的页清空,这样当运行到so里面的代码时,因为物理内存中不再有实际的数据(仅存在于虚存空间内),会产生一次缺页中断。Kernel从so文件中copy一份到内存中去,a)但是这时的全局符号表并没有经过解析,当调用到时就产生segment fault , b)如果需要的文件偏移大于新的so的地址范围,就会产生bus error。
备注:如果用相同的so去cp覆盖
A) 如果so 里面依赖了外部符号(如标准库),coredump
B) 如果so里面没有依赖外部符号,运气不错,不会coredump
不必说,先rm再cp的话,新文件的inode其实已经改变了,原inode并没有被真正删除,直到内核释放对它的引用(引用旧SO的进程退出,而新进程当然呈现的就是新so的效果了,新进程和core无关啦)。同理,mv只是改变了文件名,其inode不变,新文件使用了新的inode。
参考:
[1]http://www.piao2010.com/%E4%B8%BA%E4%BD%95cp%E8%A6%86%E7%9B%96%E8%BF%9B%E7%A8%8B%E7%9A%84%E5%8A%A8%E6%80%81%E5%BA%93so%E4%BC%9A%E5%AF%BC%E8%87%B4coredump
[2]http://blog.csdn.net/wei_yongtao/article/details/40145891