Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: nil dereference on FreeBSD in runSafePointFn #19061

Closed
ianlancetaylor opened this issue Feb 13, 2017 · 3 comments
Closed

runtime: nil dereference on FreeBSD in runSafePointFn #19061

ianlancetaylor opened this issue Feb 13, 2017 · 3 comments
Labels
FrozenDueToAge
Milestone
Go1.9

Comments

@ianlancetaylor
Copy link
Contributor

Seen on the builder: https://build.golang.org/log/ec4f681c914df48df85ebbfd344586f6a9ece205 .

This could be related to the commit being tested, https://golang.org/cl/36799, git revision 3792db5, though at the moment I don't see how.

##### ../test/bench/go1
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x42df68]

runtime stack:
runtime.throw(0x893040, 0x2a)
    /tmp/workdir/go/src/runtime/panic.go:596 +0x95
runtime.sigpanic()
    /tmp/workdir/go/src/runtime/signal_unix.go:332 +0x2db
runtime.runSafePointFn()
    /tmp/workdir/go/src/runtime/proc.go:1305 +0x58
runtime.schedule()
    /tmp/workdir/go/src/runtime/proc.go:2190 +0x2c7
runtime.park_m(0xc4200a7380)
    /tmp/workdir/go/src/runtime/proc.go:2285 +0xab
runtime.mcall(0x801400268)
    /tmp/workdir/go/src/runtime/asm_amd64.s:269 +0x5b

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc4203e92ac)
    /tmp/workdir/go/src/runtime/sema.go:61 +0x34
sync.(*WaitGroup).Wait(0xc4203e92a0)
    /tmp/workdir/go/src/sync/waitgroup.go:131 +0x72
cmd/go/internal/work.(*Builder).Do(0xc4203ed080, 0xc4203169c0)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1206 +0x490
cmd/go/internal/test.runTest(0xa870a0, 0xc420010120, 0x2, 0x2)
    /tmp/workdir/go/src/cmd/go/internal/test/test.go:650 +0x137c
main.main()
    /tmp/workdir/go/src/cmd/go/main.go:133 +0x841

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /tmp/workdir/go/src/runtime/asm_amd64.s:2184 +0x1

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
    /tmp/workdir/go/src/runtime/sigqueue.go:116 +0xa7
os/signal.loop()
    /tmp/workdir/go/src/os/signal/signal_unix.go:22 +0x22
created by os/signal.init.1
    /tmp/workdir/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 12 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc4203e92a0, 0xc4203ed080, 0xc42019f740)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1187 +0x1bd
created by cmd/go/internal/work.(*Builder).Do
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1184 +0x46f

goroutine 13 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc4203e92a0, 0xc4203ed080, 0xc42019f740)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1187 +0x1bd
created by cmd/go/internal/work.(*Builder).Do
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1184 +0x46f

goroutine 14 [runnable]:
syscall.Syscall(0x6, 0x6, 0x0, 0x0, 0x0, 0x0, 0x0)
    /tmp/workdir/go/src/syscall/asm_unix_amd64.s:19 +0x5
syscall.Close(0x6, 0xc4204e2fe0, 0x8)
    /tmp/workdir/go/src/syscall/zsyscall_freebsd_amd64.go:377 +0x4a
syscall.forkExec(0xc4202608a0, 0x2b, 0xc42025e4d0, 0xb, 0xb, 0xc4204e3168, 0x20, 0x410e7d, 0xc420156700)
    /tmp/workdir/go/src/syscall/exec_unix.go:203 +0x469
syscall.StartProcess(0xc4202608a0, 0x2b, 0xc42025e4d0, 0xb, 0xb, 0xc4204e3168, 0x2, 0x4, 0x20, 0x20)
    /tmp/workdir/go/src/syscall/exec_unix.go:240 +0x64
os.startProcess(0xc4202608a0, 0x2b, 0xc42025e4d0, 0xb, 0xb, 0xc4204e3310, 0x20, 0xc4201566e0, 0x0)
    /tmp/workdir/go/src/os/exec_posix.go:45 +0x1fb
os.StartProcess(0xc4202608a0, 0x2b, 0xc42025e4d0, 0xb, 0xb, 0xc4204e3310, 0x0, 0x0, 0xc4200a6680)
    /tmp/workdir/go/src/os/exec.go:94 +0x64
os/exec.(*Cmd).Start(0xc4204b6580, 0x0, 0xc42033ca80)
    /tmp/workdir/go/src/os/exec/exec.go:359 +0x502
os/exec.(*Cmd).Run(0xc4204b6580, 0xc42033ca80, 0x0)
    /tmp/workdir/go/src/os/exec/exec.go:277 +0x2b
cmd/go/internal/work.(*Builder).runOut(0xc4203ed080, 0x881a45, 0x1, 0x883f7d, 0x8, 0x0, 0x0, 0x0, 0xc4204e3688, 0x7, ...)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1956 +0x429
cmd/go/internal/work.(*Builder).run(0xc4203ed080, 0x881a45, 0x1, 0x883f7d, 0x8, 0x0, 0x0, 0x0, 0xc4204e3688, 0x7, ...)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1901 +0xc2
cmd/go/internal/work.gcToolchain.ld(0xc4203ed080, 0xc420316410, 0xc4202c7b80, 0x45, 0xc42049a000, 0x73, 0x80, 0xc4202c7a90, 0x43, 0x0, ...)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:2435 +0x88e
cmd/go/internal/work.(*gcToolchain).ld(0xaaa370, 0xc4203ed080, 0xc420316410, 0xc4202c7b80, 0x45, 0xc42049a000, 0x73, 0x80, 0xc4202c7a90, 0x43, ...)
    <autogenerated>:1 +0xeb
cmd/go/internal/work.(*Builder).build(0xc4203ed080, 0xc420316410, 0x0, 0x0)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1461 +0x20d1
cmd/go/internal/work.(*Builder).Do.func1(0xc420316410)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1138 +0x72
cmd/go/internal/work.(*Builder).Do.func2(0xc4203e92a0, 0xc4203ed080, 0xc42019f740)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1197 +0x145
created by cmd/go/internal/work.(*Builder).Do
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1184 +0x46f

goroutine 15 [select]:
cmd/go/internal/work.(*Builder).Do.func2(0xc4203e92a0, 0xc4203ed080, 0xc42019f740)
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1187 +0x1bd
created by cmd/go/internal/work.(*Builder).Do
    /tmp/workdir/go/src/cmd/go/internal/work/build.go:1184 +0x46f
@ianlancetaylor ianlancetaylor added this to the Go1.9 milestone Feb 13, 2017
@bradfitz
Copy link
Contributor

/cc @aclements

@ianlancetaylor
Copy link
Contributor Author

FYI the FreeBSD builder has now passed twice since that CL, so this is most likely not related to the CL.

@aclements
Copy link
Member

This has appeared twice on the dashboard:

$ greplogs -dashboard -E "runtime.runSafePointFn" -l -md
2017-02-13T18:36:28-3792db5/freebsd-amd64-gce93
2017-03-02T23:30:07-9b15c13/freebsd-amd64-gce101

The crash is clearly because sched.safePointFn is nil. I've checked over the synchronization around this carefully and I don't see anything wrong (and while there's some complex stuff going on, the non-nil-ness of runSafePointFn is pretty simple). I also checked over the generated assembly to make sure the compiler wasn't messing up the ordering of the atomics.

However, in all three cases, we're also in the middle of a forkExec. And all three failures are on FreeBSD. Hence, I strongly suspect that this is actually a dup of the infamous #15658.

@aclements aclements mentioned this issue Aug 2, 2017
Closed
@golang golang locked and limited conversation to collaborators May 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.9
Development

No branches or pull requests
4 participants
@bradfitz @aclements @ianlancetaylor @gopherbot