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