Home > Software design >  What does a go program crash without a stacktrace mean?
What does a go program crash without a stacktrace mean?

Time:08-02

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).

CodePudding user response:

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 cross compiler. Building a statically linked binary with the default cross compiler solved all crashes.

  • Related