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

runtime: "internal error: misuse of lockOSThread/unlockOSThread" in runOpenDeferFrame #35277

bcmills opened this issue Oct 31, 2019 · 4 comments


Copy link

@bcmills bcmills commented Oct 31, 2019

# cmd/go/internal/web.test
fatal error: runtime: internal error: misuse of lockOSThread/unlockOSThread

runtime stack:
runtime.throw(0x1289aa7, 0x3e)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/panic.go:1045 +0x72
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:3697 +0x36
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/asm_amd64.s:370 +0x66

goroutine 1 [running]:
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/asm_amd64.s:330 fp=0xc00075af20 sp=0xc00075af18 pc=0x105ac90
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:3690 +0x84 fp=0xc00075af40 sp=0xc00075af20 pc=0x1038a74
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:159 +0x33 fp=0xc00075af50 sp=0xc00075af40 pc=0x1059d63
runtime.call32(0x0, 0x128be78, 0xc003ca14e8, 0x800000008)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/asm_amd64.s:539 +0x3b fp=0xc00075af80 sp=0xc00075af50 pc=0x105b04b
runtime.runOpenDeferFrame(0xc000000180, 0xc003ca14a0, 0xc00075b0a0)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/panic.go:816 +0x2b5 fp=0xc00075b008 sp=0xc00075af80 pc=0x102d8a5
panic(0x1238ca0, 0x142d630)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/panic.go:909 +0x155 fp=0xc00075b0a0 sp=0xc00075b008 pc=0x102db05
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/signal_unix.go:594 +0x3da fp=0xc00075b0d0 sp=0xc00075b0a0 pc=0x10438ba
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/internal/bytealg/equal_amd64.s:102 +0xd1 fp=0xc00075b0d8 sp=0xc00075b0d0 pc=0x10024e1
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/internal/ld/deadcode.go:111 +0x4f1 fp=0xc00075b300 sp=0xc00075b0d8 pc=0x11634e1
cmd/link/internal/ld.Main(0x1431fe0, 0x10, 0x20, 0x1, 0x7, 0x10, 0x1280fdc, 0x1b, 0x127daf6, 0x14, ...)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/internal/ld/main.go:211 +0xb64 fp=0xc00075b458 sp=0xc00075b300 pc=0x11a6184
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/cmd/link/main.go:65 +0x1bc fp=0xc00075bf88 sp=0xc00075b458 pc=0x120a5bc
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:203 +0x212 fp=0xc00075bfe0 sp=0xc00075bf88 pc=0x1030102
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/asm_amd64.s:1375 +0x1 fp=0xc00075bfe8 sp=0xc00075bfe0 pc=0x105cc01
FAIL	cmd/go/internal/web [build failed]
Copy link

@randall77 randall77 commented Oct 31, 2019

Something miscompiled in runtime.main? That defer shouldn't run unlockOSThread, because at the point of the panic needUnlock has already been set to false.

Copy link

@danscales danscales commented Oct 31, 2019

I tried to reproduce by running go test -test.count=1000 cmd/go/internal/web many times on darwin-amd64-10_14, but didn't have any luck reproducing (all passed fine).

However, this might have to do with the fact that runtime.main only leaves the function via exit(0) (which is followed by an infinite loop), so there is no explicit function return/exit where inline defer code is generated. Hence, the implicit &needUnlock argument to the defer closure is not necessarily kept alive, so it may not get adjusted if there is a stack move. I should maybe just make all OpenDeferSlots live through out the entire function.

Copy link

@gopherbot gopherbot commented Nov 1, 2019

Change mentions this issue: cmd/compile: fix liveness for open-coded defer args for infinite loops

gopherbot pushed a commit that referenced this issue Nov 5, 2019
Once defined, a stack slot holding an open-coded defer arg should always be marked
live, since it may be used at any time if there is a panic. These stack slots are
typically kept live naturally by the open-defer code inlined at each return/exit point.
However, we need to do extra work to make sure that they are kept live if a
function has an infinite loop or a panic exit.

For this fix, only in the case of a function that is using open-coded defers, we
compute the set of blocks (most often empty) that cannot reach a return or a
BlockExit (panic) because of an infinite loop. Then, for each block b which
cannot reach a return or BlockExit or is a BlockExit block, we mark each defer arg
slot as live, as long as the definition of the defer arg slot dominates block b.

For this change, had to export (*Func).sdom (-> Sdom) and SparseTree.isAncestorEq
(-> IsAncestorEq)

Updates #35277

Change-Id: I7b53c9bd38ba384a3794386dd0eb94e4cbde4eb1
Run-TryBot: Dan Scales <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Keith Randall <>
Copy link

@danscales danscales commented Nov 5, 2019

Should be fixed by

@danscales danscales closed this Nov 5, 2019
@golang golang locked and limited conversation to collaborators Nov 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.