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.

Sign up for GitHub

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: "internal error: misuse of lockOSThread/unlockOSThread" in runOpenDeferFrame #35277

Closed
bcmills opened this issue Oct 31, 2019 · 4 comments
Closed

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

bcmills opened this issue Oct 31, 2019 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.14

Comments

@bcmills
Copy link
Contributor

bcmills commented Oct 31, 2019

https://build.golang.org/log/2ad3c689c702a04aa5f733d1be1310466392dc07:

# 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
runtime.badunlockosthread()
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:3697 +0x36
runtime.systemstack(0x0)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/asm_amd64.s:370 +0x66
runtime.mstart()
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/proc.go:1069

goroutine 1 [running]:
runtime.systemstack_switch()
	/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
runtime.unlockOSThread()
	/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
runtime.main.func2(0xc000070fae)
	/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
runtime.panicmem(...)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/runtime/panic.go:212
runtime.sigpanic()
	/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
memeqbody()
	/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
strings.HasPrefix(...)
	/private/var/folders/9w/4l2_g3kx01x199n37fbmv3s80000gn/T/workdir-host-darwin-10_14/go/src/strings/strings.go:449
cmd/link/internal/ld.deadcode(0xc000046000)
	/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
main.main()
	/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
runtime.main()
	/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
runtime.goexit()
	/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]
@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Oct 31, 2019
@bcmills bcmills added this to the Go1.14 milestone Oct 31, 2019
@randall77
Copy link
Contributor

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.

@danscales
Copy link
Contributor

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.

@gopherbot
Copy link

Change https://golang.org/cl/204802 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
@danscales
cmd/compile: fix liveness for open-coded defer args for infinite loops
1b3a1db 
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
Reviewed-on: https://go-review.googlesource.com/c/go/+/204802
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
@danscales
Copy link
Contributor

Should be fixed by https://golang.org/cl/204802

@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.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
4 participants
@danscales @bcmills @randall77 @gopherbot