cmd/link/internal/ld: panic in deadcode on darwin

[bcmills]

Observed on the darwin-386-10_14 builder (https://build.golang.org/log/52334b038bdb15873c9661a4bd19a514d7d57626):

# fmt.test
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x5d pc=0x13b4e4]

goroutine 1 [running]:
cmd/link/internal/ld.(*deadcodepass).flood(0x11801924)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/internal/ld/deadcode.go:352 +0x414
cmd/link/internal/ld.deadcode(0x117de000)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/internal/ld/deadcode.go:61 +0x92
cmd/link/internal/ld.Main(0x3d0380, 0x10, 0x20, 0x1, 0x4, 0x8, 0x236bde, 0x12, 0x239da0, 0x18, ...)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/internal/ld/main.go:211 +0x9a2
main.main()
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/main.go:65 +0x161
FAIL	fmt [build failed]

See previously #17140, #16887.

CC @cherrymui @mdempsky @ianlancetaylor

[odeke-em]

Thank you for the report Bryan!

Empirically that code doesn't make sense unless there perhaps was a data race or just data corruption that made s.FuncInfo nil, because the line it is failing on, given commit e764432 as per the logs, the line is

go/src/cmd/link/internal/ld/deadcode.go

Line 352 in e764432

for i := range s.FuncInfo.Funcdata {

and right before it, we explicitly checked that s.FuncInfo != nil as per

go/src/cmd/link/internal/ld/deadcode.go

Lines 351 to 355 in e764432

	if s.FuncInfo != nil {
	for i := range s.FuncInfo.Funcdata {
	d.mark(s.FuncInfo.Funcdata[i], s)
	}
	}

And that code seems to be invoked sequentially.

[bcmills]

The (*deadcodepass).flood panic seems to have been supplanted by a strings.HasPrefix panic.

2019-11-12T01:09:23-e2cac31/darwin-amd64-10_11
2019-11-10T17:12:15-40ebcfa/darwin-amd64-10_11
2019-11-07T19:18:49-69dcdbd/darwin-amd64-10_11
2019-10-29T20:10:15-1fb7d54/darwin-amd64-10_14
2019-09-02T11:13:03-4a457e3/darwin-amd64-10_11
2019-08-21T18:39:21-e764432/darwin-386-10_14

CC @thanm @jeremyfaller

[jeremyfaller]

Unusual looking bug to me. That LOC is unlikely to fail unless AllSyms has ben corrupted with a nil symbol and I don't see how that's really possible. If we check for nil at this location, we'll be playing whack-a-mole through the rest of the linker checking for nil every time we loop through AllSym.

The only three possibilities that come to mind are: some different runtime memory bug that's manifesting here, a bug in mmap for darwin, or a bad machine we just happen to get unlucky with.

[bcmills]

A bad machine seems unlikely, given the consistency of the stack trace and the number of occurrences. Either of the other two seems more plausible.

[ianlancetaylor]

2019-12-04T14:53:20-aab0280/darwin-amd64-10_11

[ianlancetaylor]

I don't see any occurrences for several months, and we've merged a new linker. Likely fixed.