一个没有堆栈跟踪的 Go 程序崩溃是什么意思?

huangapple go评论82阅读模式
英文:

What does a go program crash without a stacktrace mean?

问题

我正在一个 Kubernetes Pod 中运行一个 Go 程序,该程序中使用了 cgo。有时候 Pod 会崩溃,有时候会有回溯信息,有时候没有。

当有回溯信息时,它指向 GC 任务:

error: bad use of bucket.mp
error: non in-use span in unswept list
morestack on g0
error: non in-use span in unswept list
error: span set block with unpopped elements found in reset

设置 GODEBUG=cgocheck=2(在从 Go 到 C 的指针传递上进行缓慢、严格的有效性检查)并不能捕获到无效的指针传递。设置 GODEBUG=invalidptr=0 来防止垃圾回收器在遇到无效指针时 panic,会导致应用程序崩溃而没有堆栈跟踪。

看起来我有两个问题 -- 第一个是无效指针(来自某个地方)出现在 Go 的 GC 检查中。可以通过使用 GODEBUG=invalidptr=0 来减轻这个问题,同时调查其他问题。当一个 Go 程序崩溃时没有堆栈跟踪,这是什么意思?这可能是由于 Go 代码引起的,还是表示 C 代码存在问题?

编辑(附加数据):

这些崩溃只发生在使用 musl 编译器的 scratch Pod 中,并且在几分钟内发生。如果我使用默认的 CC 编译二进制文件,并在 Pod 中的 debian 容器中运行,程序能够正常运行而不崩溃(已经运行了 3 小时)。

英文:

I am running a go program in a kubernetes pod, and there is cgo usage in the app. The pod crashes, sometimes with a traceback, sometimes without.

When there is a traceback, it points to GC tasks:

error: bad use of bucket.mp
error: non in-use span in unswept list
morestack on g0
error: non in-use span in unswept list
error: span set block with unpopped elements found in reset

Setting GODEBUG=cgocheck=2 (slow, strict validity checks on pointer passing from go->c) does not lead to catching invalid pointer passing. Setting GODEBUG=invalidptr=0 to prevent the garbage collector from panic'ing on invalid pointers leads to the app exclusively crashing without a stack trace.

It seems I have 2 problems -- the first is invalid pointers (from somewhere) ending up in go's GC checks. This can be mitigated while the other problems are investigated with GODEBUG=invalidptr=0. What does it mean when a go program crashes without a stack trace? Could go code cause this, or does this indicate a problem in the c code?

Edit (additional data):

These crashes only happen in scratch pod (using musl compiler), and happen within a matter of minutes. If I compile the binary using the default CC and run in a debian container in the pod, the program is able to run without crashing (has been the case for 3 hours).

答案1

得分: 0

我加入了Gopher Slack,并发布了这个Stack Overflow链接。有人指出musl在Go工具链中不是100%兼容的C编译器。使用默认的C编译器构建一个静态链接的二进制文件解决了所有的崩溃问题。

英文:

I joined the gopher slack and posted this stack overflow link. I was pointed to the fact that musl is not 100% compatible as a c compiler in the go toolchain. Building a statically linked binary with the default c compiler solved all crashes.

huangapple
  • 本文由 发表于 2022年7月29日 21:57:41
  • 转载请务必保留本文链接:https://go.coder-hub.com/73167758.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定