Note that darwin/arm64 is a first class port.

CC @jeremyfaller for routing.

Before the "gap" the darwin-arm64-corellium was the iOS builder. They may not be related.

Bad click. No intention to close.

Before the "gap" the darwin-arm64-corellium was the iOS builder. They may not be related.

Agreed. (I'm much more concerned about this new one, because I think it's more likely to reflect a source of crashes on real users' hardware.)

From the message it seems the bad pointer is 0x14000270000, found at *(0x14000130050+0x8), but later on

*(object+8) = 0x5 <==

It looks like the memory content is changing between the two reads, so there is something concurrently writing to the object. But 5 is also not a valid pointer value. So from the other writer's perspective this field should not be a pointer?

This may be interesting, or may be completely red-herring:

The object's content looks a lot like some frames' arguments on some of the stacks:

 *(object+0) = 0x140006d4257
 *(object+8) = 0x5 <==
 *(object+16) = 0x16f923847
 *(object+24) = 0x7
 *(object+32) = 0x14000026e20
 *(object+40) = 0x1c
 *(object+48) = 0x1400002a07f
 *(object+56) = 0x10
 *(object+64) = 0x1
 *(object+72) = 0x1

goroutine 262

cmd/go/internal/load.loadPackageData({0x100b3abe8, 0x14000028160}, {0x140006d4261, 0x3}, {0x16f923847, 0x7}, {0x14000026e20, 0x1c}, {0x1400002a07f, 0x10}, ...)

goroutine 264

cmd/go/internal/load.loadPackageData({0x100b3abe8, 0x14000028160}, {0x140006d4271, 0x6}, {0x16f923847, 0x7}, {0x14000026e20, 0x1c}, {0x1400002a07f, 0x10}, ...)

goroutine 135

cmd/go/internal/load.loadPackageData({0x100b3abe8, 0x14000028160}, {0x140006d4151, 0x7}, {0x16f923847, 0x7}, {0x14000026e20, 0x1c}, {0x1400002a07f, 0x10}, ...)

goroutine 266

cmd/go/internal/load.loadPackageData({0x100b3abe8, 0x14000028160}, {0x140006d4291, 0x7}, {0x16f923847, 0x7}, {0x14000026e20, 0x1c}, {0x1400002a07f, 0x10}, ...)

object+16 and later words match exactly with the third and later arguments. object+0 and object+8 are also quite close to the second arguments. However, the object's address, 0x14000130050, doesn't match any of the stacks, and it is on an mSpanInUse span instead of a mSpanManual.

@cherrymui Could it be a layout object (stackArgs?) used by reflect.Call?

That function is not called by reflect call, so probably not.

Could also be a closure, I guess.

That call is at https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/load/pkg.go;l=1028
It is in a closure but the closure would capture parent, instead of parent.ImportPath, parent.Dir, parent.Root and other arguments in that order. The order of the fields in the bad object also doesn't match the parent object.

This has not happened again. Optimistically closing.