runtime: mysterious bit set of a high order bit causes segfaults and bounds check failures

[findleyr]

#!watchflakes
post <- goarch == "ppc64" && ((log ~ `SIGSEGV` && log ~ `0x0x8000`) || (log ~ `runtime error: index out of range`))

New segfault found in the gopls tests.

2023-11-20 18:35 linux-ppc64-sid-buildlet tools@8966034e go@ddb38c3f x/tools/gopls/internal/regtest/marker (log)

SIGSEGV: segmentation violation
PC=0x28e6c m=9 sigcode=3 addr=0x800000000b53940

goroutine 0 gp=0xc00070fa00 m=9 mp=0xc000744008 [idle]:
runtime.(*mspan).typePointersOfUnchecked(0xc00b8b0000?, 0xc00b959d70?)
	/workdir/go/src/runtime/mbitmap_allocheaders.go:202 +0x4c fp=0xc000fade38 sp=0xc000faddf8 pc=0x28e6c
runtime.scanobject(0xc00b8b0000, 0xc00004fc48)
	/workdir/go/src/runtime/mgcmark.go:1446 +0xcc fp=0xc000faded0 sp=0xc000fade38 pc=0x360fc
runtime.gcDrainN(0xc00004fc48, 0x10000)
	/workdir/go/src/runtime/mgcmark.go:1331 +0x1f0 fp=0xc000fadf10 sp=0xc000faded0 pc=0x35e30
...
r18  0xc00004ea08	r19  0xc000050a30
r20  0xa8	r21  0xc000744008
r22  0xc000faa3a0	r23  0xc000fadeb8
r24  0x5a	r25  0xf0
r26  0xc0129eaa1b	r27  0xc0129eaa17
r28  0x0	r29  0xc000050a28
r30  0xc00070fa00	r31  0x360fc
pc   0x28e6c	ctr  0x7fff9bdf04d0
link 0x360fc	xer  0x20000000
ccr  0x44428084	trap 0x380

— watchflakes

Originally posted by @gopherbot in #63736 (comment)

[findleyr]

CC @mknyszek

[mknyszek]

Interesting, it's segfaulting on the type pointer. That pointer also doesn't look like it's nil, either, which makes this very odd.

So far it looks like this has only failed on linux-ppc64? Is that right?

[findleyr]

@mknyszek that's the only failure I've observed, but it might be worth checking with greplogs.

[mknyszek]

Hey @golang/ppc64, is there something special about where the type metadata (from the binary) is placed in the address space? i.e. does 0x800000000b53940 look like it could plausibly be a type pointer, or does it look completely bogus?

[mknyszek]

@findleyr Thanks. greplogs shows nothing else as well.

[pmur]

I'd err on the side of bogus. I think mapped memory usually falls below 0x8000000000000000 on PPC64 in most cases. ppc64/linux doesn't support PIC, so all static data/text should occupy fairly low addresses starting at 0x10000.

[mknyszek]

There was another failure, this time unrelated to typePointersOfUnchecked, with a similar segfault on a similar address. This makes me think it's more general memory corruption.

https://build.golang.org/log/cbb742b677c36b578951d0a9b5589c1dc223a1c1

[mknyszek]

Here's another: https://build.golang.org/log/2e1a99a1002b4c9ff4b2eda9186e89a362194211