沒有堆棧跟蹤的 go 程序崩潰是什么意思？

Question

我在 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以防止垃圾收集器在無效指針上發生恐慌會導致應用程序在沒有堆棧跟蹤的情況下完全崩潰。

看來我有兩個問題——第一個是無效指針（來自某處）最終進入 go 的 GC 檢查。 這可以在使用GODEBUG=invalidptr=0調查其他問題時得到緩解。 go 程序在沒有堆棧跟蹤的情況下崩潰是什么意思？ go 代碼是否會導致此問題，或者這是否表明 c 代碼存在問題？

編輯（附加數據）：

這些崩潰只發生在臨時 pod 中（使用 musl 編譯器），並且會在幾分鍾內發生。 如果我使用默認 CC 編譯二進制文件並在 pod 中的 debian 容器中運行，則程序能夠運行而不會崩潰（已經運行了 3 個小時）。

Answer 1

我加入了 gopher slack 並發布了這個堆棧溢出鏈接。 有人指出， musl作為交叉編譯器並不是 100% 兼容的。 使用默認交叉編譯器構建靜態鏈接的二進制文件解決了所有崩潰問題。