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

cmd/compile: -l=4 triggers "write barrier prohibited by caller; oneNewExtraM" #22342

Closed
mdempsky opened this issue Oct 19, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@mdempsky
Copy link
Member

commented Oct 19, 2017

$ go build -a -gcflags=-l=4 runtime
# runtime
../src/runtime/proc.go:1655:10: write barrier prohibited by caller; oneNewExtraM
        /home/mdempsky/wd/go/src/runtime/proc.go:1618:16: called by newextram
        /home/mdempsky/wd/go/src/runtime/proc.go:1200:11: called by mstart1
        /home/mdempsky/wd/go/src/runtime/proc.go:1170:9: called by mstart

It's complaining about the mp.curg = gp asignment in oneNewExtraM. This is a pointer assignment, and type runtime.g is not labeled go:notinheap.

mstart is labeled go:nowritebarrierrec, and none of mstart1, newextram, or oneNewExtraM are labeled go:yeswritebarrierrec.

I suspect there's also a compiler bug here that this isn't being detected at -l=0, but filing as a runtime bug first for investigation.

/cc @aclements

@mdempsky

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2017

Oh, nevermind, there's an mstartm0 call in between, which is labeled yeswritebarrierrec.

This is a compiler bug.

@mdempsky mdempsky changed the title runtime: -l=4 triggers "write barrier prohibited by caller; oneNewExtraM" cmd/compile: -l=4 triggers "write barrier prohibited by caller; oneNewExtraM" Oct 19, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Oct 19, 2017

I attempted, and failed, to fix the general issue with losing function annotations during inlining in CL 41152 by disallowing inlining that would break function-level analysis. Besides not working, this was sort of an unfortunate approach. It would be much nicer if we could push the function annotations into inlining points and still analyze them correctly.

@gopherbot

This comment has been minimized.

Copy link

commented Oct 20, 2017

Change https://golang.org/cl/72132 mentions this issue: cmd/compile: prevent inlining go:yeswritebarrierrec functions

@gopherbot gopherbot closed this in 4e64ee4 Oct 20, 2017

@golang golang locked and limited conversation to collaborators Oct 20, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.