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

0
8

最近有同事在搞编译环境迁移,碰上一个问题让我帮他看一下。
他建了一个新目录,然后把现在的代码拷过去,编译的时候发现有一个文件编译不了一执行就出现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不行,则需要梳理出程序运行步骤,猜测在那一步出现问题。简化或者跳过该步骤看问题是否能重现。如果可以说明猜测正确,如不行则继续其它猜测。

<

发布回复

请输入评论!
请输入你的名字