Not really sure what to do with this bug, given the failure mode. Normally I would lease a builder and run some test or set of tests in a loop to try to reproduce -- in this case, even if I were able to reproduce it a few times, what then? I don't see any commonality in terms of the symbols that are suddenly being switched from reachable to unreachable.
“possible memory corruption on FreeBSD” is #46272, open since May. 😩
Still, it seems odd to me that this particular failure mode doesn't show up in the logs until recently. Maybe the memory corruption has a non-trivial interaction with the 1.18 GC changes? (Perhaps the corruption is triggered by having the GC active during some step of the linking process?)
I kicked off a goswarm on freebsd-amd64-12_2 this morning trying to reproduce the issue. I'll leave it running for a day or two and see if that catches any new instances of the bug. I tried to do something similar for an AMD-specific VM (e.g. netbsd-amd64-9_0-n2d) but all.bash crashes almost immediately there (most of the time doesn't make it past the bootstrap).
I ran a goswarm test (using the updated freebsd-amd64-13_0 builder image to include the fix) and did not detect any new failures over the course of a 40 hour run with 10 gomotes, so I am going to go ahead and close out this bug. See #46272 for more details on the kernel problem and the fix.