程序core了，看到的还是问号

C程序发布的时候，经常去掉-g编译选项的，那么这就遇到一个问题，当程序运行core dump后，想去调试查看core的具体信息，会发现很多符号都被优化掉了，看到的栈信息要么是问号，要么变量无法打印值； 去掉符号表，却可以让程序体积更小，而且不容易泄漏程序的信息，更安全些。

这就产生了矛盾，我们在运行的时候不需要符号表，调试的时候需要符合表，那我们能否把符号表在发布程序的时候删除，调试的时候加载符号表信息那，这样就满足了需要。

为了直观起见，先写个简单的c代码用于演示，代码如下：

编译下：

gdb调试看看：

可以看到显示没有调试符号表信息，我们重新用-g编译选项试试：

其实也不是完全没有符号，也还是有不少的，只是没有调试信息，可以用命令查看：

两个符号表的大小是有差距的差距6个,这个表示符号表的index的个数。 查下段表更清晰：

编译的时候可以采用-g编译，然后发布的时候去掉符号表，可以使用命令：strip。 如下最简单的处理下：

可以看到strip处理过的testdebug，比不用-g 选项的编译出来的test文件更小，通过nm命令验证下，确实任何符号都被删除了，而不用-g编译的文件还可以看到符号信息的。

默认情况下不会产生core文件，加大core文件尺寸：

重新编译运行：

看薯如下core的信息：

调试下看看：

因为没有符号信息，很可惜看不到具体的符号信息，也不知道在哪里core了。

看重点，加载符号文件，这个是直接加载没有strip前的文件，是包含符号表的。我们清晰的可以看到逗穗core的位置是在第8行。

我们通过命令： eu-strip testdebug -f testdebug.sym 提取testdebug中的符号表，山手卜保存为文件testdebug.sym。

我们gdb调试的时候导入这个符号试试：

多线程程序运行一段时间产生core文件，gdb调亮昌试的时候显示发生了段错误，但定位不错段错误的位置，显示如下：[*]Program terminated with signal 11, Segmentation fault.[*]#0 0x47e10000 in ? ()[*](gdb) bt[*]#0 0x47e10000 in ? ()[*]#1 0x47e10000 in ? ()Backtrace stopped: previous frame identical to this frame (corrupt stack?)程序使用的动态库都已经通过set solib-absolute-prefix和set solib-search-path 命令设置好碰键陪了，gdb的时候也没有提示找不到的符号之类的信息。但函数名却一直是问号，搞不懂什么原因笑蠢。还有就是程序中没有递归调用为什么frame 0 与 frame 1的地址是一样的？除了使用gdb还有没有其他方法可以定位到出错的位置呢？

1、首先是运行程序遇到这样的错误段错误(核心已转储）。

2、打开产简乎生core文件的指令拦春悉。

3、再次运行出现错误的程序。

4、使用gdb指令运行core文件，排查森塌错误"。

---