一个proc预编译代码时coredump的问题分析
2019-12-22 16:03:30来源:博客园 阅读 ()
一个proc预编译代码时coredump的问题分析
最近有同事在搞编译环境迁移,碰上一个问题让我帮他看一下。
他建了一个新目录,然后把现在的代码拷过去,编译的时候发现有一个文件编译不了一执行就出现core,不知道啥情况。
我进到他的编译环境,执行make,果然出现了core文件。
使用file命令分析,发现是proc程序的core。于是使用gdb,想进去看看在哪里core了。
但打开后使用where命令,发现输出的函数名称全是问号。根据经验,这种一般是由于内存越界导致函数堆栈信息被破坏。
于是想试试在gdb里面执行程序,看能不能抓到core现场。
使用make -n,输出实际编译的命令。再使用gdb运行porc,设置好运行参数,运行程序。
运行后很快出现sigsegv错误,这时使用where命令,发现函数堆栈信息还在。
但函数名称很陌生,不是库函数,又没源码,从函数名称也判断不出具体出错原因。于是断了使用gdb找原因的想法。
然后我又想,有一些文件编译成功,但有一些文件编译失败。会不会是这个.pc文件里面有什么代码触发了proc的bug呢?
于是我把文件里面的代码进行删减,再编译。
但无论我怎么删,运行proc预编译都会coredump。说明应该不是代码问题。
难道是文件名字导致的?
于是我把出错的代码恢复,并将其改名成另一个可以编译过的代码文件的名称。再编译一试,发现可以正常运行。
接着我再找了一个能成功编译的代码,使用mv命令把它改名成失败的代码名称,发现预编译出现core。
经过这两个试验,可以确定是文件名称导致了proc出现coredump。观察成功和失败的代码文件名称,发现长度相差比较大。
会不会是文件名长度造成的呢?
于是我通过逐步加大文件名试验,慢慢定位,终于发现proc在iname参数超过100个字符的时候会出现异常。
因为我这个同事新建的目录路径太长,导致路径名+文件名超过了100个字符,之前旧编译环境目录路径比较短,所以没有发现这个问题.
由于没有保留现场,相应的操作截图无法展示。这篇文章主要是想介绍一个常用的定位程序问题思路:
1 直接从结果分析,看core文件,错误日志,是否有明确提示问题所在
2 如果1不行,则需要梳理出程序运行步骤,猜测在那一步出现问题。简化或者跳过该步骤看问题是否能重现。如果可以说明猜测正确,如不行则继续其它猜测。
原文链接:https://www.cnblogs.com/kingstarer/p/12079989.html
如有疑问请与原作者联系
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
上一篇:c++-多态小案例
- 一个工业级、跨平台、轻量级的 tcp 网络服务框架:gevent 2020-06-05
- C++ 在名称空间中使用using声明和using编译指令 2020-05-29
- 分享一个自己项目中用到的c++版的日志类(对初学者十分有用的 2020-05-22
- C++ 单独编译 2020-05-10
- 图 2020-05-02
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash