英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论