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: fatal error: missed stack barrier #18571

Closed
b-s-a opened this issue Jan 9, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@b-s-a
Copy link

commented Jan 9, 2017

A program with pprof enabled (net/http/pprof imported) compiled with Go 1.7.3 panics sometime (one per 2 weeks or rare) with: fatal error: missed stack barrier

OS: Debian 7 x86_64
go version go1.7.3 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/go-1.7"
GOTOOLDIR="/usr/lib/go-1.7/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build721289951=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

log1.txt
log2.txt

@ALTree ALTree changed the title fatal error: missed stack barrier runtime: fatal error: missed stack barrier Jan 9, 2017

@ALTree

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

Is the code free of data races (did you try building/running with -race)?
Did you by chance test it with the go1.8beta2? Does it happen with go1.8?

@dsnet

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

Thanks for the report. Additional question:

  • Is there any unsafe or cgo involved?
@b-s-a

This comment has been minimized.

Copy link
Author

commented Jan 9, 2017

There are no any cgo and unsafe imports.
I have not tested with -race, so I do it soon, thank you for it.

@b-s-a

This comment has been minimized.

Copy link
Author

commented Jan 9, 2017

I cannot reproduce bug on my machine with go1.7. But I do not want to use go1.8 on production.

-race shows only one place - read/write boolean variable. I have rewrite this part of code, and will test it on production soon...

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2017

When you say "I cannot reproduce bug on my machine with go1.7" did you mean to say go1.8?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 9, 2017

@b-s-a

This comment has been minimized.

Copy link
Author

commented Jan 9, 2017

I cannot reproduce on my machine, because I cannot load it as production server and cannot wait for weeks...

Currently I suggest to suspend this discussion, because compiler used was 1.5 (I open binary and find go1.5 string in it). debian package system did not use 1.7. So I completely recompile my program and put on production. Currently I will wait for 1 month to reproduce bug. If it is not reproduced, then bug should be closed as invalid.

@ALTree

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

If you were using 1.5 you could be seeing #12932 (?)

@b-s-a

This comment has been minimized.

Copy link
Author

commented Jan 9, 2017

It is very possible, because this bug is reason why I try to use 1.7 which is not present in debian 7, so my installation was incorrect.

@aclements

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

Based on the line numbers in the traceback, I can confirm that this binary was actually built with Go 1.5.1. Since we're no longer supporting Go 1.5, I'm going to close this bug.

It's likely the @ALTree is right and what you're seeing is #12932. That was fixed in Go 1.6 and backported for Go 1.5.2, so upgrading should fix the problem.

@aclements aclements closed this Jan 9, 2017

@golang golang locked and limited conversation to collaborators Jan 9, 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.