菜单 学习猿地 - LMONKEY

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

zhijianzhuang profile image zhijianzhuang ・1 min read

    最近有同事在搞编译环境迁移,碰上一个问题让我帮他看一下。
    他建了一个新目录,然后把现在的代码拷过去,编译的时候发现有一个文件编译不了一执行就出现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个字符,之前旧编译环境目录路径比较短,所以没有发现这个问题.

评论 (0)