最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月,当然,和人手不足也有关系。而对于我个人而言,这个问题其实历时2年!这得从头说起。
在上一家公司的一个项目里,有一个服务做音视频数据的提取,这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件,这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式,问题的症状是服务运行一段时间后,不输出音视频数据。遗憾的是,由于疫情,项目停止,因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试,发现关键的语音处理服务运行一段时间后,会出现不拉流的情况,因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样,但同样用了go和c混编的方式。一开始,焦点就放在go的运行时上,觉得可能是go和c相互调用的方式不对。经过合理猜测,并用测试进行验证后,发现问题还是在第三方拉流的SDK上,它们的回调函数必须要快,否则有可能会阻塞它们的回调线程。当然,在go调用c的时候,如果耗时比较长,会对go的运行时造成一些副作用;在c回调go的时候,go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟,因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法,主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中,使用了gdb的gcore来生成堆栈;也搭建了灰度环境来进行压力测试,以及完善监控,这些都是解决方法的一部分。
正是这一问题,促使我更多的了解go的运行时。而我看得越多,越觉得go的运行时是一个庞大的怪物。因此,抱着能了解一点是一点的心态,不断的完善这篇笔记。
是Go语言吗?Go 编译过程 九个步骤
第一步. all.bash
% cd $GOROOT/src
% ./all.bash
第一步 all.bash 只是调用了另外两个 shell 脚本:make.bash 和run.bash。若使用 Windows 或 Plan9,其过程也基本类似,只是脚本分别以 .bat 或 .rc 结尾。在文章的其他部分,请用适当的操作系统对应的扩展来补全命令。
第二步. make.bash
. ./make.bash --no-banner
make.bash 作为 all.bash 内容的一部分,如果它退出也会中断构建过程
第三步. cmd/dist
gcc -O2 -Wall -Werror -ggdb -o cmd/dist/dist -Icmd/dist cmd/dist/*.c
当健全检查完成后,make.bash 开始编译 cmd/dist。
第四步. go_bootstrap
现在 go_bootstrap 已经构建完成,make.bash 的最后一步是使用 go_bootstrap 编译完整的 Go 标准库,包括一个完整的 go 工具用以替换。
echo "# Building packages and commands for $GOOS/$GOARCH."
"$GOTOOLDIR"/go_bootstrap install -gcflags "$GO_GCFLAGS" \
-ldflags "$GO_LDFLAGS" -v std
第五步. run.bash
现在 make.bash 已经完成,回到 all.bash 的执行,这会调用 run.bash。run.bash 的任务是编译和测试标准库、运行时以及语言测试集。
bash run.bash --no-rebuild
由于 make.bash 和 run.bash 都会调用 go install -a std,因此需要使用 –no-rebuild 标志来避免重复前面的步骤,–no-rebuild 跳过了第二个 go install。
# allow all.bash to avoid double-build of everythingrebuild=trueif [ "$1" = "--no-rebuild" ]then shiftelse echo '# Building packages and commands.' time go install -a -v std echofi
第六步. go test -a std
echo '# Testing packages.'
time go test std -short -timeout=$(expr 120 \* $timeout_scale)s
echo
接下来 run.bash 会在标准库里所有的包上来运行用 testing 包编写的单元测试。由于 $GOPATH 和 $GOROOT 中有着相同的命名空间,所以不能直接使用 go test … 否则 $GOPATH 中的每个包也会被逐一测试,因此创建了一个用于标准库中的包的别名:std。由于一些测试需要比较长的时间,且会消耗大量内存,因此用 -short 标志对一些测试进行了过滤。
第七步. runtime 和 cgo 测试
run.bash 接下来的部分会运行平台对 cgo 支持的测试,执行一些性能测试,并且编译一些伴随 Go 发行版一起的杂项程序。随着时间的流逝,这些杂项程序的清单会越来越长,那么它们也就会不可避免的被从编译过程中悄悄剥离出去。
第八步. go run test
(xcd ../test
unset GOMAXPROCS
time go run run.go
) || exit $?
run.bash 的倒数第二步会调用在 $GOROOT 下的 test 目录里的编译器和运行时的测试。他们是对于编译器和运行时自身的,较为低级细节的测试。会执行语言规格测试,test/bugs 和 test/fixedbugs 子目录保存有那些已经被发现并被修复的问题的独立的测试。驱动测试的是一个小 Go 程序 $GOROOT/test/run.go,会执行 test 目录里的每个 .go 文件。一些 .go 文件的首行包含了指导 run.go 对结果作出判断的指令,例如,程序将会失败,或提供一个确定的输出队列。
第九步. go tool api
echo '# Checking API compatibility.'
go tool api -c $GOROOT/api/go1.txt,$GOROOT/api/go1.1.txt \
-next $GOROOT/api/next.txt -except $GOROOT/api/except.txt
run.bash 的最后一步调用了 api 工具。