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

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

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

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

mdempsky opened this issue Oct 19, 2017 · 3 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@mdempsky
Copy link
Member 

$ 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 mdempsky added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 19, 2017
@mdempsky
Copy link
Member Author

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
Copy link
Member

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
Copy link

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

@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.
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.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mdempsky @aclements @gopherbot