查看原文
其他

深度细节 | Go 的 panic 的三种诞生方式

脚本之家 2022-05-10

The following article is from 奇伢云存储 Author 奇伢

 关注脚本之家”,与百万开发者在一起
作者 | 奇伢
出品 | 奇伢云存储(ID: qiyacloud)
坚持思考,就会很酷



为什么 panic 值得思考?


初学 Go 的时候,心里常常很多疑问,有时候看似懂了的问题,其实是是而非。

panic 究竟是啥?看似显而易见的问题,但是却回答不出个所以然来。奇伢分两个章节来彻底搞懂 panic 的知识:

  • 姿势篇:摸清楚 panic 的诞生,它不是石头里蹦出来的,总结有三种姿势;
  • 原理篇:彻底搞明白 panic 的内部原理,理解 panic 的深层原理;

panic 的三种姿势


什么时候会产生 panic ?

我们先从“形”来学习。从程序猿的角度来看,可以分为主动和被动方式,被动的方式有两种,如下:

主动方式

  • 程序猿主动调用 panic( ) 函数;

被动的方式

  • 编译器的隐藏代码触发;
  • 内核发送给进程信号触发 ;

编译器的隐藏代码


Go 之所以简单又强大,编译器居功至伟。非常多的事情是编译器帮程序猿做了的,逻辑补充,内存的逃逸分析等等。

包括 panic 的抛出!

举个非常典型的例子:整数算法除零会发生 panic,怎么做到的?

看一段极简代码:

func divzero(a, b int) int {
    c := a/b
    return c
}

上面函数就会有除零的风险,当 b 等于 0 的时候,程序就会触发  panic,然后退出,如下:

root@ubuntu:~/code/gopher/src/panic# ./test_zero 

panic: runtime error: integer divide by zero

goroutine 1 [running]:
main.zero(0x64, 0x0, 0x0)
 /root/code/gopher/src/panic/test_zero.go:6 +0x52

问题来了:程序怎么触发的 panic ?

代码面前无秘密。

可代码看不出啥呀,不就是一行 c := a/b 嘛?

奇伢说的是汇编代码因为这段隐藏起来的逻辑,是编译器帮你加的。

用 dlv 调试断点到 divzero 函数,然后执行 disassemble ,你就能看到秘密了。奇伢截取部分汇编,并备注了下:

(dlv) disassemble
TEXT main.zero(SB) /root/code/gopher/src/panic/test_zero.go

// 判断 b 是否等于 0
test_zero.go:6 0x4aa3c1 4885c9 test rcx, rcx
// 不等于 0 就跳转到 0x4aa3c8 执行指令,否则就往下执行
test_zero.go:6 0x4aa3c4 7502 jnz 0x4aa3c8
// 执行到这里,就说明 b 是 0 值,就跳转到 0x4aa3ed ,也就是 call $runtime.panicdivide
=> test_zero.go:6 0x4aa3c6 eb25 jmp 0x4aa3ed
test_zero.go:6 0x4aa3c8 4883f9ff cmp rcx, -0x1
test_zero.go:6 0x4aa3cc 7407 jz 0x4aa3d5
test_zero.go:6 0x4aa3ce 4899 cqo
test_zero.go:6 0x4aa3d0 48f7f9 idiv rcx
// ...
test_zero.go:7 0x4aa3ec c3 ret
// 看到神奇的函数了嘛 !
test_zero.go:6 0x4aa3ed e8ee27f8ff call $runtime.panicdivide

看到秘密的函数了吗?

编译器偷偷加上了一段 if/else 的判断逻辑,并且还给加了 runtime.panicdivide  的代码。

  1. 如果 b == 0 ,那么跳转执行函数 runtime.panicdivide ;

再来看一眼 panicdivide 函数,这是一段极简的封装:

// runtime/panic.go
func panicdivide() {
    panicCheck2("integer divide by zero")
    panic(divideError)
}

看到了不,这里面调用的就是 panic() 函数。

除零触发的 panic 就是这样来的,它不是石头里蹦出来的,而是编译器多加的逻辑判断保证了除数为 0 的时候,触发 panic 函数。

划重点:编译器加的隐藏逻辑,调用了抛出 panic 的函数。Go 的编译器才是真大佬!


进程信号触发


最典型的是非法地址访问,比如, nil 指针 访问会触发 panic,怎么做到的?

看一个极简的例子:

func nilptr(b *int) int {
    c := *b
    return c
}

当调用 nilptr( nil ) 的时候,将会导致进程异常退出:

root@ubuntu:~/code/gopher/src/panic# ./test_nil 

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x4aa3bc]

goroutine 1 [running]:
main.nilptr(0x0, 0x0)
 /root/code/gopher/src/panic/test_nil.go:6 +0x1c

问题来了:这里的 panic 又是怎么形成的呢?

在 Go 进程启动的时候会注册默认的信号处理程序( sigtramp )

在 cpu 访问到 0 地址会触发 page fault 异常,这是一个非法地址,内核会发送 SIGSEGV 信号给进程,所以当收到 SIGSEGV 信号的时候,就会让 sigtramp 函数来处理,最终调用到 panic 函数 :

// 信号处理函数回调
sigtramp (纯汇编代码)
  -> sigtrampgo ( signal_unix.go )
    -> sighandler  ( signal_sighandler.go )
       -> preparePanic ( signal_amd64x.go )

          -> sigpanic ( signal_unix.go )
           -> panicmem 
              -> panic (内存段错误)

在 sigpanic 函数中会调用到 panicmem  ,在这个里面就会调用 panic 函数,从而走上了 Go 自己的 panic 之路。

panicmem 和 panicdivide 类似,都是对 panic( ) 的极简封装:

func panicmem() {
    panicCheck2("invalid memory address or nil pointer dereference")
    panic(memoryError)
}

划重点:这种方式是通过信号软中断的方式来走到 Go 注册的信号处理逻辑,从而调用到 panic( )  的函数。

童鞋可能会好奇,信号处理的逻辑什么时候注册进去的?

在进程初始化的时候,创建 M0(线程)的时候用系统调用 sigaction 给信号注册处理函数为 sigtramp ,调用栈如下:

mstartm0 (proc.go)
    -> initsig (signal_unix.go:113)
        -> setsig (os_linux.go)

这样的话,以后触发了信号软中断,就能调用到 Go 的信号处理函数,从而进行语言层面的 panic 处理 。

总的来说,这个是从系统层面到特定语言层面的处理转变。


程序猿主动


第三种方式,就是程序猿自己主动调用 panic 抛出来的。

func main() {
    panic("panic test")
}

简单的函数调用,这个超简单的。


聊聊 panic 到底是什么?


现在我们摸透了 panic 产生的姿势,以上三种方式,无论哪一种都归一到 panic( ) 这个函数调用。所以有一点很明确:panic 这个东西是语言层面的处理逻辑。


panic 发生之后,如果 Go 不做任何特殊处理,默认行为是打印堆栈,退出程序。

现在回到最本源的问题:panic 到底是什么?

这里不纠结概念,只描述几个简单的事实:

  1. panic( ) 函数内部会产生一个关键的数据结构体 _panic ,并且挂接到 goroutine 之上;
  2. panic( ) 函数内部会执行 _defer 函数链条,并针对 _panic 的状态进行对应的处理

什么叫做 panic( ) 的对应的处理?

循环执行 goroutine 上面的 _defer 函数链,如果执行完了都还没有恢复 _panic 的状态,那就没得办法了,退出进程,打印堆栈

如果在 goroutine 的 _defer 链上,有个朋友 recover 了一下,把这个 _panic 标记成恢复,那事情就到此为止,就从这个 _defer 函数执行后续正常代码即可,走 deferreturn 的逻辑。

所以,panic 是什么 ?

小奇伢认为,它就是个特殊函数调用,仅此而已。

有多特殊?

限于篇幅,此处不表,下篇剖析其深度原理。

给读者朋友先思考几个小问题,下次我们一起揭秘:

  • panic 究竟是啥?是一个结构体?还是一个函数?
  • 为什么 panic 会让 Go 进程退出的 ?
  • 为什么 recover 一定要放在 defer 里面才生效?
  • 为什么 recover 已经放在 defer 里面,但是进程还是没有恢复?
  • 为什么 panic 之后,还能再 panic ?有啥影响?


总结


  1. panic 产生的三大姿势:程序猿主动,编译器辅助逻辑,软中断信号触发
  2. 无论哪一种姿势,最终都是归一到 panic( ) 函数的处理,panic 只是语言层面的处理逻辑
  3. panic 发生之后,如果不做处理,默认行为是打印 panic 原因,打印堆栈,进程退出;

  推荐阅读:

50 万行Go代码,美国一组织从Python 2迁移到 Go

它曾是浏览器的王者,如今却前景堪忧......

Go 并发编程 — 结构体多字段的原子操作

每日打卡赢积分兑换书籍入口

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存