linux下so覆盖导致coredump问题的分析
2016-09-15 00:22
423 查看
转载地址:http://blog.sina.com.cn/s/blog_622a99700100pjv3.html
尝试解答以下问题:
1.为什么cp的方式更新运行中进程的so,程序会coredump
2.采用什么方式更新已经加载了的so,就可以避免coredump
我们的公共组件绝大部分都支持so形式的自定义插件,比如s++,qzhttp,ttc。在不停进程更新so的时候往往会产生coredump,并且肯定core得莫名其妙,core得让人心碎。
先看一下用cp的方式更新so的时候发生了什么事情
strace cp new.so old.so #strace是人间利器
发现老的so被trunc了,这个过程发生的具体的事情是:
1.应用程序通过dlopen打开so的时候,kernel通过mmap把so加载到进程地址空间,对应于vma里的几个page.
2.在这个过程中loader会把so里面引用的外部符号例如malloc
printf等解析成真正的虚存地址。
3.当so被cp覆盖时,确切地说是被trunc时,kernel会把so文件在虚拟内的页purge 掉。
4.当运行到so里面的代码时,因为物理内存中不再有实际的数据(仅存在于虚存空间内),会产生一次缺页中断。
5.Kernel从so文件中copy一份到内存中去,a)但是这时的全局符号表并没有经过解析,当调用到时就产生segment
fault , b)如果需要的文件偏移大于新的so的地址范围,就会产生bus error.
所以,如果用相同的so去覆盖
A) 如果so 里面依赖了外部符号,coredump
B) 如果so里面没有依赖外部符号,运气不错,不会coredump
所有问题的产生都是因为so被trunc了一把,所以如果不用turnc的方式就避免这个问题。Ok,该我们的install 上场了。
strace install new.so old.so
install 的方式跟cp不同,先unlink再creat,当unlink的时候,已经map的虚拟空间vma中的inode结点没有变,只有inode结点的引用计数为0是,kernel才把它干掉。
也就是新的so和旧的so用的不是同一个inode结点,所以不会相互影响。这时只有得启程序才会使用到新的so。所以采用这种方式的话就可以避免先stop进程,更新so,再重启进程这样比较耗时的操作。
尝试解答以下问题:
1.为什么cp的方式更新运行中进程的so,程序会coredump
2.采用什么方式更新已经加载了的so,就可以避免coredump
我们的公共组件绝大部分都支持so形式的自定义插件,比如s++,qzhttp,ttc。在不停进程更新so的时候往往会产生coredump,并且肯定core得莫名其妙,core得让人心碎。
先看一下用cp的方式更新so的时候发生了什么事情
strace cp new.so old.so #strace是人间利器
发现老的so被trunc了,这个过程发生的具体的事情是:
1.应用程序通过dlopen打开so的时候,kernel通过mmap把so加载到进程地址空间,对应于vma里的几个page.
2.在这个过程中loader会把so里面引用的外部符号例如malloc
printf等解析成真正的虚存地址。
3.当so被cp覆盖时,确切地说是被trunc时,kernel会把so文件在虚拟内的页purge 掉。
4.当运行到so里面的代码时,因为物理内存中不再有实际的数据(仅存在于虚存空间内),会产生一次缺页中断。
5.Kernel从so文件中copy一份到内存中去,a)但是这时的全局符号表并没有经过解析,当调用到时就产生segment
fault , b)如果需要的文件偏移大于新的so的地址范围,就会产生bus error.
所以,如果用相同的so去覆盖
A) 如果so 里面依赖了外部符号,coredump
B) 如果so里面没有依赖外部符号,运气不错,不会coredump
所有问题的产生都是因为so被trunc了一把,所以如果不用turnc的方式就避免这个问题。Ok,该我们的install 上场了。
strace install new.so old.so
install 的方式跟cp不同,先unlink再creat,当unlink的时候,已经map的虚拟空间vma中的inode结点没有变,只有inode结点的引用计数为0是,kernel才把它干掉。
也就是新的so和旧的so用的不是同一个inode结点,所以不会相互影响。这时只有得启程序才会使用到新的so。所以采用这种方式的话就可以避免先stop进程,更新so,再重启进程这样比较耗时的操作。
相关文章推荐
- linux下So覆盖导致coredump问题的分析
- linux下So覆盖导致coredump问题的分析
- linux下So覆盖导致coredump问题的分析
- GDB分析PHP连接Memcached 导致coredump问题
- Linux内核分析:页回收导致的cpu load瞬间飙高的问题分析与思考--------------蘑菇街技术博客
- GDB分析PHP连接Memcached 导致coredump问题
- linux下错误使用pthread_mutex_lock导致程序奔溃问题分析
- Linux内核分析:页回收导致的cpu load瞬间飙高的问题分析与思考
- linux字体配置问题之修改字族名称导致的覆盖问题
- Linux下TCP延迟确认(Delayed Ack)机制导致的时延问题分析
- Linux下TCP延迟确认(Delayed Ack)机制导致的时延问题分析
- linux替换运行程序或so动态库文件导致的问题
- linux之alias导致覆盖提示问题?
- 一次因内存覆盖引起的system dump问题分析,基于linux的crash工具。
- Linux开发心得总结2 - 频繁分配释放内存导致的性能问题的分析
- Linux下mp3标签乱码问题的分析和解决
- 多线程问题导致的JDBMonitor的bug分析
- 注册表不能写入导致不能安装office问题分析
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- Windows和linux换行符差异导致的问题