golang中的panic，recover执行过程?
上篇文章golang中defer的执行过程是怎样的？介绍了一下defer的执行过程，本篇是上一篇的引伸，主要介绍panic、recover的底层分析，若是没有读过上一篇文章，能够先去读一下在看这篇。 总共分3部分讲解：linux
1 panic
2 defer panic
3 defer panic recover
环境：go version go1.12.5 linux/amd64golang
1 panic
golang中的异常总共分为4中：sass
- 编译器捕获的
- 直接手动panic
- golang捕获的
- 系统捕获的
编译器捕获的
1/0 咱们知道被除数是不能等于0的，因此这种错误是编译不过去的，会提示： ./main.go:7:8: division by zerobash
直接手动panic
示例代码：数据结构
package main
func main() {
panic("panic error！！")
}
复制代码
编译成汇编代码看panic函数会指向底层哪一个函数： go tool compile -S main.go > main.s函数
0x0034 00052 (main.go:4) CALL runtime.gopanic(SB)
复制代码
查看gopanic(SB)实现，先粗略看一下代码的含义一些解释在代码中已经注解：post
func gopanic(e interface{}) {
gp := getg() //获取当前的g
....省略不重要的
var p _panic //_panic原型
p.arg = e //将panic参数存入arg参数
p.link = gp._panic //将p.link绑定到当前的g的_panic上。
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p))) //将p绑定到g的链表头。
atomic.Xadd(&runningPanicDefers, 1)
for {
d := gp._defer
if d == nil {
break
}
if d.started {
if d._panic != nil {
d._panic.aborted = true
}
d._panic = nil
d.fn = nil
gp._defer = d.link
freedefer(d)
continue
}
d.started = true
d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))//将p绑定到g的链表头。
p.argp = unsafe.Pointer(getargp(0))
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz)) //调用g上的defer(源程序中若是没有defer函数，编译器会生成一个并绑定到g._defer上)
p.argp = nil
if gp._defer != d {
throw("bad defer entry in panic")
}
//脱链
d._panic = nil
d.fn = nil
gp._defer = d.link
pc := d.pc
sp := unsafe.Pointer(d.sp) // must be pointer so it gets adjusted during stack copy
freedefer(d)
if p.recovered { //先忽略讲到recover时候在说
.....
}
}
preprintpanics(gp._panic)
//循环打印panic
fatalpanic(gp._panic) // should not return
*(*int)(nil) = 0 // not reached
}
复制代码
咱们发现panic的原型是_panic,去看一下定义：ui
type _panic struct {
argp unsafe.Pointer // pointer to arguments of deferred call run during panic; cannot move - known to liblink
arg interface{} // argument to panic
link *_panic // link to earlier panic
recovered bool // whether this panic is over
aborted bool // the panic was aborted
}
复制代码
发现是个结构体类型，里面的类型咱们在调试代码的时候在去探究具体的含义。 接下来咱们就用gdb跟踪一下上面的源码示例。this
go build -o main gdb mainatom
进入gdb界面并断点到panic函数行见下图：
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
复制代码
原来当前的gp定义（因为不是讲goroutine 这里就不贴gp的原型了）中有_panc字段做为链表头,而_panic结构体中有link字段。不难看出和defer同理：从goroutine._panic做为头，而后用_painc.link做为连接组成了一个链表的数据结构。之因此是链表是由于recover到panic时候，recover中也有可能有panic，例如见下方代码：
if err := recover(); err != nil {
panic("go on panic xitehip")
}
复制代码
deferd函数也会继续有panic。下方讲到recover时候详细讲解。 执行上面的语句此时的链表示意结构见下方： gp._panic => p.link => gp._panic(以前的链表头) 继续往下走：
func reflectcall(argtype *_type, fn, arg unsafe.Pointer, argsize uint32, retoffset uint32)
复制代码
从第二个参数可知这个是函数指针，猜想这个reflectcall是调用咱们实参unsafe.Point(d.fn)的。根据源码中的定义 d := gp._defer可知变量d就是上文咱们说的g._defer。那立刻有疑问了，这个例子里根本没有用到defer关键字，就不会调用deferproc(SB)生成defer。那只有一种可能就是编译器帮咱们作了生成了一个defer函数而后绑定到了g._defer的链表头上。 继续看reflectcall函数见下图x：
0x0000000000423025，咱们去看一下reflectcall函数执行完的返回值是如何指向到红线处的指令的。 见下方汇编代码：
//runtime/asm_amd64.s
TEXT ·reflectcall(SB), NOSPLIT, $0-32
MOVLQZX argsize+24(FP), CX
DISPATCH(runtime·call32, 32)
DISPATCH(runtime·call64, 64)
.....
MOVQ $runtime·badreflectcall(SB), AX
JMP AX
复制代码
//runtime/asm_amd64.s
#define DISPATCH(NAME,MAXSIZE) \
CMPQ CX, $MAXSIZE; \
JA 3(PC); \
MOVQ $NAME(SB), AX; \
JMP AX
复制代码
//runtime/asm_amd64.s
#define CALLFN(NAME,MAXSIZE) \
TEXT NAME(SB), WRAPPER, $MAXSIZE-32; \
NO_LOCAL_POINTERS; \
/* copy arguments to stack */ \
MOVQ argptr+16(FP), SI; \
MOVLQZX argsize+24(FP), CX; \
MOVQ SP, DI; \
REP;MOVSB; \
/* call function */ \
MOVQ f+8(FP), DX; \
PCDATA $PCDATA_StackMapIndex, $0; \
CALL (DX); \
/* copy return values back */ \
MOVQ argtype+0(FP), DX; \
MOVQ argptr+16(FP), DI; \
MOVLQZX argsize+24(FP), CX; \
MOVLQZX retoffset+28(FP), BX; \
MOVQ SP, SI; \
ADDQ BX, DI; \
ADDQ BX, SI; \
SUBQ BX, CX; \
CALL callRet<>(SB); \
RET
复制代码
是否是很乱，这些是啥？？用gdb跟踪一下到： 运行到下图：
TEXT callRet<>(SB), NOSPLIT, $32-0
复制代码
那红框ret处就是reflectcall的返回。打到断点到ret处。 执行到这里见下图：
0x423025 所指向的内容：
p.argp = nil 翻译成汇编代码就是图y中的
mov QWROD PTR [rsp+0x58],0x0，就是变量赋值会把值存入栈中而不是寄存器中。
d._panic = nil
d.fn = nil
gp._defer = d.link
复制代码
运行到：
func fatalpanic(msgs *_panic)
复制代码
进行打印输出，看一下实现：
func fatalpanic(msgs *_panic) {
pc := getcallerpc()
sp := getcallersp()
gp := getg()
var docrash bool
systemstack(func() {
if startpanic_m() && msgs != nil {
atomic.Xadd(&runningPanicDefers, -1)
printpanics(msgs)
}
docrash = dopanic_m(gp, pc, sp)
})
if docrash {
crash()
}
systemstack(func() {
exit(2)
})
*(*int)(nil) = 0 // not reached
}
复制代码
重点看以下函数：
printpanics(msgs)
复制代码
实现：
func printpanics(p *_panic) {
if p.link != nil {
printpanics(p.link)
print("\t")
}
print("panic: ")
printany(p.arg)
if p.recovered {
print(" [recovered]")
}
print("\n")
}
复制代码
发现这个是个递归调用，从g._panic链表头开始直到链表结束而后打印出panic信息。
golang捕获的
例如slice越界，见下方代码：
package main
import "fmt"
func main() {
arr := []int{1, 2}
arr[2] = 3
fmt.Println(arr)
}
复制代码
会panic： panic: runtime error: index out of range 编译成汇编代码：go tool compile -S main.go > main.s
0x003c 00060 (main.go:7) CALL runtime.panicindex(SB)
复制代码
可知调用了panicindex(SB) 去看一下它的实现：
func panicindex() {
if hasPrefix(funcname(findfunc(getcallerpc())), "runtime.") {
throw(string(indexError.(errorString)))
}
panicCheckMalloc(indexError)
panic(indexError)
}
复制代码
发现最终仍是会调用panic(interface{})这个函数，而后就是上面所说的手动panic的执行流程，在这里不在重复赘述。
系统捕获的
好比对只读内存区赋值操做会引发panic
package main
import "fmt"
func main() {
var pi *int
*pi = 100
fmt.Printf("%v", *pi)
}
复制代码
会报以下错误： panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x488a53] goroutine 1 [running]: main.main() /server/gotest/src/hello/defer/main.go:7 +0x3a
编译成汇编代码没有发现gopanic入口。由于最终输出panic栈的信息，因此确定调用了gopanic，给gopanic()打上断点直接运行到这里见下图：
*pi = 100生成的汇编代码：
划红线处：test BYTE PTR [ax], al 因为ax=0x0因此BYTE PTR [ax]是获取不到0x0的内存的。这样cpu执行这条语句的时候会进入内核态保存0x488b1a到寄存器，内核态发送消息给go进程，go处理函数将0x488b1a所指向的内容换成go启动时事先注册号的函数做为指令入口，回到内核态执行0x488b1a -> 注册函数的指令。具体的调用链在这里就不深究了重点仍是panic，recover。
2 defer panic
2.1示例：
package main
import "fmt"
func main() {
defer fmt.Println("d1")
defer fmt.Println("d2")
panic("panic error")
}
复制代码
输出： d2 d1 panic error 以下核心代码：
//runtime/panic.go
func gopanic(e interface{}) {
for {
...//获取goroutine表头deferd
//执行表头的deferd
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
...//将表头的deferd拖链，将下一个deferd绑定到表头
}
...
fatalpanic(gp._panic) // 运行递归调用gp._panic链表上的panic
...
}
复制代码
从上面代码可知，gopanic先遍历deferd链在遍历panic链，因此panic error最后输出。
2.2示例：
第14行panic -> gopanic() -> reflectcall -> 第12行defer -> reflectcall -> 第8行defer -> 第9行panic -> gopanic -> reflectcall -> 继续执行deferd链上的也就是第6行defer -> fatalpanic(里面子函数printpanics()递归调用g._panic链)。
3 defer panic recover
下面介绍的是recover的执行过程，先看下方示例代码：
package main
import "fmt"
func main() {
re()
fmt.Println("After recovery!")
}
func re() {
defer func() {
if err := recover(); err != nil {
fmt.Println("err:", err)
}
}()
panic("panic error1")
}
复制代码
输出： err: panic error1 After recovery!
recover()的做用是捕获异常以后让程序正常往下执行而不会退出。这个例子里re()函数里有了异常，而且被捕获而后执行了re()下面的代码输出'After recovery'。
那为何执行完recover()以后会跳转到输出行执行呢？
从汇编角度考虑：执行完re()以后要想保证继续往下执行，首先要把下一行的入口地址存起来，而后recover()以后再去取回来，放到rip指令寄存器中这样才能够向下执行。
在re()里除了deferd函数还有有panic()这行，那很明显它的内部实现里会有相关实现，继续分析recover的实现和panic内部的相关实现。
汇编查看recover()：go tool compile -S main.go 发现gorecover(SB),猜想是recover()的实现:
0x002a 00042 (main.go:13) CALL runtime.gorecover(SB)
复制代码
在recover()行打断点,发现确实执行了gorecover(SB)函数，实现以下：
func gorecover(argp uintptr) interface{} {
gp := getg()
p := gp._panic
if p != nil && !p.recovered && argp == uintptr(p.argp) {
p.recovered = true
return p.arg
}
return nil
}
复制代码
从以上代码可知gorecover(uintptr)只是把当前goroutine的_panic.recovered 设置为true，而后返回以前panic函数设置的参数(err)给调用方。其实就是将当前的g._panic设置个标致，告诉之后的程序说我已经被捕获到了。
这个有recover()的deferd函数执行完以后会返回到上面提到的gopanic(interface{})函数中的reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))下一行继续往下执行。 见下方代码：
func gopanic(e interfac{}) {
.......
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
//往下看：
p.argp = nil
if gp._defer != d {
throw("bad defer entry in panic")
}
//执行完defered函数以后脱链
d._panic = nil
d.fn = nil
gp._defer = d.link
pc := d.pc //deferproc()函数中存入的放回值地址
sp := unsafe.Pointer(d.sp) //
freedefer(d)
if p.recovered {//执行了gorecover()函数以后p.recovered == true
atomic.Xadd(&runningPanicDefers, -1)
gp._panic = p.link
for gp._panic != nil && gp._panic.aborted {
gp._panic = gp._panic.link
}
if gp._panic == nil { // must be done with signal
gp.sig = 0
}
gp.sigcode0 = uintptr(sp)
gp.sigcode1 = pc //pc恢复栈做用。
mcall(recovery)
throw("recovery failed") // mcall should not return
}
......
}
复制代码
看一下这行代码：
pc := d.pc
复制代码
pc是什么呢？它是上篇文章中提到的deferproc()函数中存入的，见下方代码：
func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
...
callerpc := getcallerpc()
d := newdefer(siz)
if d._panic != nil {
throw("deferproc: d.panic != nil after newdefer")
}
d.fn = fn
d.pc = callerpc
....
复制代码
咱们在下方截图的第12行打一断点来看一下pc中究竟是啥。看一下绿框中的指令：
test eax, eax的地址是
0x4872d5稍后会再次说到这个指令及地址。
继续断点执行到d.pc = callerpc以后，咱们看一下d.pc究竟是什么值，见下图：
0x4872d5这不是刚刚说的上图绿框处
test eax, eax的指令地址吗。带着疑问继续往下看。
从上面gorecover(uintptr)函数代码可知 p.recoverd == true 因此gopanic()中会执行到if p.recovered {里，咱们着重看两行代码：
gp.sigcode1 = pc
复制代码
将pc就是deferproc()函数的返回值赋值给gp.sigcode1，为返回到正常流程作准备。
mcall(recovery)
复制代码
其中的mcall先不看,先看recovery函数做用,见下方实现：
func recovery(gp *g) {
// Info about defer passed in G struct.
sp := gp.sigcode0
pc := gp.sigcode1
// d's arguments need to be in the stack. if sp != 0 && (sp < gp.stack.lo || gp.stack.hi < sp) { print("recover: ", hex(sp), " not in [", hex(gp.stack.lo), ", ", hex(gp.stack.hi), "]\n") throw("bad recovery") } // Make the deferproc for this d return again, // this time returning 1. The calling function will // jump to the standard return epilogue. gp.sched.sp = sp gp.sched.pc = pc gp.sched.lr = 0 gp.sched.ret = 1 gogo(&gp.sched) } 复制代码
recovery(*g) 主要是gp.sched赋值。其中pc是当前deferproc函数的返回地址。咱们再看一下gogo(&gp.sched)函数实现，由于gogo函数是用汇编实现的因此用gdb跟踪是最方便的见下方代码：
TEXT runtime·gogo(SB), NOSPLIT, $16-8
MOVQ buf+0(FP), BX // gobuf
MOVQ gobuf_g(BX), DX
MOVQ 0(DX), CX // make sure g != nil
get_tls(CX)
MOVQ DX, g(CX)
MOVQ gobuf_sp(BX), SP // restore SP
MOVQ gobuf_ret(BX), AX
MOVQ gobuf_ctxt(BX), DX
MOVQ gobuf_bp(BX), BP
MOVQ $0, gobuf_sp(BX) // clear to help garbage collector
MOVQ $0, gobuf_ret(BX)
MOVQ $0, gobuf_ctxt(BX)
MOVQ $0, gobuf_bp(BX)
MOVQ gobuf_pc(BX), BX
JMP BX
复制代码
着重看2行代码:
MOVQ gobuf_ret(BX), AX
复制代码
AX从某个值变成了1，这个指令的偏移数量是gobuf_ret,其中的ret不就是返回的意思吗，见下图。
再看最后一条指令：
JMP BX
复制代码
看一下BX究竟是啥：
0x4872d5吗，对应的指令是
test eax,eax。再重看一下这个图：
test eax, eax
jne 0x4872f9
复制代码
的意思是若是eax不等于0就跳转到这个地址不然就去执行绿框处第三行的正常流程。由于eax已经不等0了，因此就会跳转到0x4872f9这个地址处，跟踪一下这个地址指向的是哪里，见下图:
runtime.deferreturn()函数,见下图。
sp := getcallersp() sp是调用者的sp。就是即将调用defer func() {时的sp。 d.sp 是调用链上第二个defer，由于第一个deferd已经脱链。 显然这两个不相等，因此return了，具体return底层究竟是如何将re()的返回地址返回的就不在跟踪了。而后执行到了下放的入口地址处：
fmt.Println("After recovery!")
复制代码
整个流程，参看下图代码而后解释：
call re() => 将re()返回值压栈到栈顶 => 执行12行defer函数 => 执行deferproc():将deferproc返回值存入pc，调用者(re())栈顶存入到sp,将defered函数加入到链表头，返回0（return0函数做用是将ax设为0） => 返回到下方代码test eax eax处 => 因为ax=0继续运行到17行的panic() =>gopanic() => 调用reflectcall():执行deferd函数 => 执行recovery():将recoverd标志位设为1 => mcall(recovery) => gogo():ax设为1，跳转到pc处 => 再一次跳转到test eax, eax :因为ax=1 => 跳转到deferreturn()函数:callersp !=d.sp，这里的d.sp中的d其实已是是g上面默认带的_defer了，因此不等 => return 获取re()的返回地址pop到rip处 => cpu执行其返回值 => 输出'After recovery'
...
//defer函数 =>deferproc
0x00000000004872d0 <+48>: call 0x426c00 <runtime.deferproc>
0x00000000004872d5 <+53>: test eax,eax
0x00000000004872d7 <+55>: jne 0x4872f9 <main.re+89>
0x00000000004872d9 <+57>: jmp 0x4872db <main.re+59>
0x00000000004872db <+59>: lea rax,[rip+0x111be] # 0x4984a0
0x00000000004872e2 <+66>: mov QWORD PTR [rsp],rax
0x00000000004872e6 <+70>: lea rax,[rip+0x48643]
0x00000000004872ed <+77>: mov QWORD PTR [rsp+0x8],rax
//panic() => gopanic
0x00000000004872f2 <+82>: call 0x427880 <runtime.gopanic>
...
复制代码
recover()的核心其实就是defer函数生成的汇编指令：判断跳转区分正常流程仍是获取返回值流程。见上方汇编代码。 机器指令是从上往下执行，正常流程是执行完deferproc以后再执行panic()生成的gopanic()。获取返回值流程必然须要跳转到某处获取，而golang的设计者放到了deferreturn()函数中因此最终要跳到这里来。
留个疑问下方代码如何输出，为何？
package main
import "fmt"
func main() {
re()
fmt.Println("After recovery!")
}
func re() {
defer func() {
if err := recover(); err != nil {
fmt.Println("Recover again:", err)
}
}()
defer func() {
if err := recover(); err != nil {
switch v := err.(type) {
case string:
panic(string(v))
}
}
}()
panic("start panic")
}
复制代码