写了个很常见的能导致core的go程序
```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)
没有,所以做了个比较猥琐的事情。
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的方法定位问题了。
#7