I've made some progress with these fails. A lot of the confusion is around the way gccgo hooks the SEGV handler and attempts to backtrace all goroutines (the code is in runtime_tracebackothers())
It does this by calling runtime_gogo() which temporarily switches to the goroutine using setcontext(). If the context is bad in any way, this will cause us to SEGV again. I printed out the stack pointer (r1) and the NIA during this stack backtracing, and we see where things go south just as we are about to dump goroutine 0:
I've made some progress with these fails. A lot of the confusion is around the way gccgo hooks the SEGV handler and attempts to backtrace all goroutines (the code is in runtime_ tracebackothers ())
It does this by calling runtime_gogo() which temporarily switches to the goroutine using setcontext(). If the context is bad in any way, this will cause us to SEGV again. I printed out the stack pointer (r1) and the NIA during this stack backtracing, and we see where things go south just as we are about to dump goroutine 0:
goroutine 0 [idle]:
DEBUG: runtime_gogo r1 0 nia 0
r1 = 0, nia = 0. When we call setcontext on this invalid context we die with:
jujud[5258]: bad frame in setup_rt_frame: 0000000000000000 nip 0000000000000000 lr 0000000000000000
Perhaps we aren't saving away the context for goroutine 0 correctly.