一个proc预编译代码时coredump的问题分析

2019-12-22 16:03:30来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

一个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++-多态小案例

下一篇:51.Qt-使用ajax获取ashx接口的post数据