gdb调试go生成的core文件栈信息为??

写了个很常见的能导致core的go程序

package main

func main() {
        var a map[int]int
        a[0] = 0

        return
}

设置环境变量 export GOTRACEBACK=crash

然后使用go build -gcflags "-N -l" 进行编译，运行程序，会生成core文件，然后我使用gdb main core.16996 查看 core文件，但是看到栈信息看不到自己的代码部分，无法定位哪里core了，请问下是我编译参数有问题还是怎么的呢？

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /data/sx/interface/src/BrokerGateway/main/main...done.
[New Thread 16996]
[New Thread 16997]
[New Thread 16999]
[New Thread 16998]
[New Thread 17000]
Core was generated by `./main'.
Program terminated with signal 6, Aborted.
#0  runtime.raise () at /data/sx/interface/3party/go/go安装包/go/src/runtime/sys_linux_amd64.s:110
110             RET
(gdb) bt
#0  runtime.raise () at /data/sx/interface/3party/go/go安装包/go/src/runtime/sys_linux_amd64.s:110
#1  0x0000000000433228 in runtime.dieFromSignal (sig=6) at /data/sx/interface/3party/go/go安装包/go/src/runtime/signal1_unix.go:192
#2  0x000000000043334f in runtime.crash () at /data/sx/interface/3party/go/go安装包/go/src/runtime/signal1_unix.go:247
#3  0x000000000042421e in runtime.dopanic_m (gp=0xc820000180, pc=4339638, sp=859530599912) at /data/sx/interface/3party/go/go安装包/go/src/runtime/panic.go:642
#4  0x00000000004442f2 in runtime.dopanic.func1 () at /data/sx/interface/3party/go/go安装包/go/src/runtime/panic.go:517
#5  0x000000000044c4c9 in runtime.systemstack () at /data/sx/interface/3party/go/go安装包/go/src/runtime/asm_amd64.s:291
#6  0x0000000000427f70 in runtime.startTheWorldWithSema () at /data/sx/interface/3party/go/go安装包/go/src/runtime/proc.go:983
#7  0x00000000004b8500 in runtime.g0 ()
#8  0x00007fffb8538340 in ?? ()
#9  0x00000000004b84c0 in runtime.work ()
#10 0x0000000000427fe2 in runtime.mstart () at /data/sx/interface/3party/go/go安装包/go/src/runtime/proc.go:1065
#11 0x000000000044c2c8 in runtime.rt0_go () at /data/sx/interface/3party/go/go安装包/go/src/runtime/asm_amd64.s:149
#12 0x0000000000000001 in ?? ()
#13 0x00007fffb8538388 in ?? ()
#14 0x0000000000000001 in ?? ()
#15 0x00007fffb8538388 in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)

defer func() { if err := recover(); err != nil { //打印栈信息 stack := debug.Stack() log.Print(string(stack)) panic(err) //这里也可以温和的自己控制退出 }

wslzwps · #1 · 9年之前

解决了吗？我现在也遇到了同样的问题。

jorions · #2 · 8年之前

楼主问题解决了吗？

highfly43 · #3 · 8年之前

对

wslzwps #1 回复

使用gdb调试go代码的时候可以看到栈信息，但是调试core的时候还是一样。。

highfly43 · #4 · 8年之前

jorions #2 回复

jorions · #5 · 8年之前

highfly43 #4 回复

#2楼 @jorions 使用gdb调试go代码的时候可以看到栈信息，但是调试core的时候还是一样。。

是的，我调试运行的时候添加了日志找到我程序的问题了

georgehuang · #6 · 8年之前

楼主，问题解决了吗？求分享

highfly43 · #7 · 8年之前

georgehuang #6 回复

没有，所以做了个比较猥琐的事情。

在自己所有的协程的defer里面控制如果core了就打印栈信息，像这样：

}()

然后程序core的时候会往标准错误输出栈信息，所以启动的时候把标准错误输出定位到一个文件2>core.info

虽然没有解决用gdb解析core文件的问题，但是只能退而求其次用这种比较ws的方法定位问题了。

georgehuang · #8 · 8年之前

highfly43 #7 回复

#6楼 @georgehuang 没有，所以做了个比较猥琐的事情。 1. 在自己所有的协程的defer里面控制如果core了就打印栈信息，像这样： defer func() { if err := recover(); err != nil { //打印栈信息 stack := debug.Stack() log.Print(string(stack)) panic(err) //这里也可以温和的自己控制退出 } }() 2. 然后程序core的时候会往标准错误输出栈信息，所以启动的时候把标准错误输出定位到一个文件2>core.info 虽然没有解决用gdb解析core文件的问题，但是只能退而求其次用这种比较ws的方法定位问题了。

多谢呀，我周一也去试试手动捕获panic。。理论上正常情况程序在core时会把栈信息打印出来的，然而这次我却没有看到有输出，你这里之前也是遇到同样的问题了吗？

用户登录

今日阅读排行

一周阅读排行

关注我