runtime/trace: failure with SIGSEGV (and no other output) on linux-ppc64-buildlet

[bcmills]

signal: segmentation fault (core dumped)
FAIL	runtime/trace	2.104s

greplogs -l -e 'signal: segmentation fault \(core dumped\)\nFAIL\s+runtime/trace' --since=2022-01-01
2022-09-06T15:49:30-c35bc69/linux-ppc64-buildlet

(CC @golang/runtime @golang/ppc64)

[pmur]

I started looking into this. I was able to to reproduce a similar segfault on the VM on the same commit. I was able to get a core and save it off.

The backtrace of the fault:

#0  0x000000000006f2e8 in runtime.gentraceback (pc0=145060, sp0=824637013152, lr0=<optimized out>, gp=0xc000003d40, skip=0, pcbuf=0xc0003709e8, max=64, 
    callback={void (runtime.stkframe *, void *, bool *)} 0xc0003709c0, v=0x0, flags=6, ~r0=<optimized out>) at /workdir/go/src/go/src/runtime/traceback.go:162
#1  0x0000000000054974 in runtime.sigprof (pc=<optimized out>, sp=<optimized out>, lr=<optimized out>, gp=<optimized out>, mp=0xc0000e5000) at /workdir/go/src/go/src/runtime/proc.go:4626
#2  0x000000000005fbec in runtime.sighandler (sig=<optimized out>, info=<optimized out>, ctxt=<optimized out>, gp=<optimized out>) at /workdir/go/src/go/src/runtime/signal_unix.go:631
#3  0x000000000005f200 in runtime.sigtrampgo (sig=27, info=0xc000371d78, ctx=0xc000371000) at /workdir/go/src/go/src/runtime/signal_unix.go:479
#4  0x000000000007eee8 in runtime.sigtrampgo (sig=27, info=0xc000371d78, ctx=0xc000371000) at <autogenerated>:1
#5  0x000000000007df28 in sigtramp () at /workdir/go/src/go/src/runtime/sys_linux_ppc64x.s:559

[bcmills]

Hmm, the fault in gentraceback suggests a possible connection to #50144, although that could also be an independent bug with a similar failure mode. 🤔

[pmur]

At the point of failure, I see that, gp.m == nil caused the fault in if flags&_TraceJumpStack != 0 && gp == gp.m.g0 && gp.m.curg != nil .

[cherrymui]

CL https://golang.org/cl/428656 is supposed to fix the nil m case. Is the failure before or after that CL? Thanks.

[pmur]

@cherrymui, this is 2 commits prior to that patch.

Though, if gp.m is nil, won't this still segfault when executing gp == gp.m.g0?

[prattmic]

That check is guarding on the previous loop iteration. i.e., in the previous loop gp.m.curg.m == nil. Once we set gp = gp.m.curg, then next iteration will crash on gp.m.g0.

[pmur]

I am not able to reproduce this with CL 428655. I think this has been fixed by CL 428656.