一个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不行，则须要梳理出程序运行步骤，猜想在那一步出现问题。简化或者跳过该步骤看问题是否能重现。若是能够说明猜想正确，如不行则继续其它猜想。