Navigation Menu

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

Segmentation fault at pkg/runtime/proc.c:2273 #7065

Closed
gopherbot opened this issue Jan 5, 2014 · 25 comments
Closed

Segmentation fault at pkg/runtime/proc.c:2273 #7065

gopherbot opened this issue Jan 5, 2014 · 25 comments
Milestone

Comments

@gopherbot
Copy link

by guohouzuo:

What steps will reproduce the problem?

Sorry! I have not been able to make a small & reproducible example. See additional
information below.

Which compiler are you using (5g, 6g, 8g, gccgo)?

Golang 1.2, downloaded and compiled by Homebrew

Which operating system are you using?

OSX Mavericks, Darwin 13.0 64-bit

Which version are you using?  (run 'go version')

go version go1.2 darwin/amd64

Please provide any additional information below.

In the middle of debugging a performance issue in my project tiedot, I turned on CPU
profiling (runtime/pprof), and the segmentation fault happens at a very small chance.
The stack trace of fault is:

SIGSEGV: segmentation violation
PC=0x1e382

acquirep(0x0)
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/proc.c:2273 +0x52
stopm()
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/proc.c:940 +0x157
findrunnable()
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/proc.c:1237 +0x42d
schedule()
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/proc.c:1320 +0xe3
park0(0x22663d5a0)
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/proc.c:1361 +0xd8
runtime.mcall(0x29af2)
    /usr/local/Cellar/go/1.2/libexec/src/pkg/runtime/asm_amd64.s:178 +0x4b

Complete stacktrace of all dumped goroutines is attached.

Attachments:

  1. complete_goroutine_trace (25285 bytes)
@dvyukov
Copy link
Member

dvyukov commented Jan 9, 2014

Comment 1:

It seems that a thread is woken w/o m->nextp. If it can happen, then it would crash with
the same stack trace. But I have not seen such crashes before. It's possible that it
crashes with a very low probability.
It seems to be an open-source project. Can you provide reproduction instructions?

Labels changed: added release-go1.3maybe, repo-main.

@gopherbot
Copy link
Author

Comment 2 by guohouzuo:

Thanks Dmitry. I will soon try my best to make a minimized reproducible.

@dvyukov
Copy link
Member

dvyukov commented Jan 9, 2014

Comment 3:

To make it clear, I do not care too much about size of the involved code base. Do if can
just provide commands that I need to execute and necessary input data (if any), that
would be enough for starters.

@dvyukov
Copy link
Member

dvyukov commented Jan 9, 2014

Comment 4:

Labels changed: added release-go1.2.1, removed release-go1.3maybe.

@gopherbot
Copy link
Author

Comment 5 by guohouzuo:

Hello Dmitry.
Please clone tiedot "segfault" branch:
    https://github.com/HouzuoGuo/tiedot/tree/segfault
And compile it as per usual:
    go build
To trigger the segfault, run the compiled executable with flag -bench3:
    ./tiedot -bench3
Clean up happens automatically before each run, so no manual cleanup is required.
It almost always completes successfully, but the segfault happens every 40 or 50 runs.
I attach another segfault goroutine trace.
Thanks!

Attachments:

  1. goroutine_trace2 (22370 bytes)

@dvyukov
Copy link
Member

dvyukov commented Jan 10, 2014

Comment 6:

I don't know whether I guessed how to do these steps correctly or not. My checkout seems
to be on segfault:
gopath/src/github.com/HouzuoGuo/tiedot$ git status
On branch segfault
Your branch is up-to-date with 'origin/segfault'.
But the binary does not recognize -bench3:
$ ./tiedot -bench3
flag provided but not defined: -bench3
Usage of ./tiedot:

@gopherbot
Copy link
Author

Comment 7 by guohouzuo:

Oops, my apologize, I was supposed to say:
    ./tiedot -mode=bench3

@dvyukov
Copy link
Member

dvyukov commented Jan 10, 2014

Comment 8:

Can run it now. No crashes yet.
You've said that if happens only if you enable CPU profiling. Do I need to do anything
special to enable it? Or it is enabled by default?

@dvyukov
Copy link
Member

dvyukov commented Jan 10, 2014

Comment 9:

When I run it, it consumes 50+GB of memory. Is it possible to limit amount of memory it
consumes?

@gopherbot
Copy link
Author

Comment 10 by guohouzuo:

Hello Dmitry.
CPU profile is already enabled in the code, see line 296 in benchmark.go.
It sounds very unusual to consume 50+GB of memory. On my system, the peak resident
memory usage is around 2GB.
Out of curiosity, are you running tiedot on a OSX system?

@dvyukov
Copy link
Member

dvyukov commented Jan 12, 2014

Comment 11:

Owner changed to @dvyukov.

Status changed to Accepted.

@dvyukov
Copy link
Member

dvyukov commented Jan 12, 2014

Comment 12:

>CPU profile is already enabled in the code, see line 296 in benchmark.go.
Ah, OK, I see. However note that CPU profiling was disabled on OSX in Go 1.2... So I am
not sure how it affects the issue...
> It sounds very unusual to consume 50+GB of memory. On my system, the peak resident
memory usage is around 2GB.
No, that was linux 64-bit. I wanted to see whether it reproduces there.
I was able to reproduce it on tip on OSX so far.

@dvyukov
Copy link
Member

dvyukov commented Jan 12, 2014

Comment 13:

I suspect it may be related to 
https://golang.org/issue/5139

@gopherbot
Copy link
Author

Comment 14 by guohouzuo:

Thanks Dmitry.
So... the performance output has been inaccurate and useless hahaha. I have tried very
hard to optimise tiedot according to the output!

@gopherbot
Copy link
Author

Comment 15 by guohouzuo:

By the way, it never crashes with segfault with CPU profiling turned off... at least it
hasn't happened to me.

@dvyukov
Copy link
Member

dvyukov commented Jan 12, 2014

Comment 16:

How many times have you seen it? Have you seen any other crashes, like "notewakeup -
double wakeup"?

@gopherbot
Copy link
Author

Comment 17 by guohouzuo:

Double wakup has never happened to me.
The segfault has happened three times so far - twice before I submitted the bug report,
and once when I cut the branch to reproduce it.

@dvyukov
Copy link
Member

dvyukov commented Jan 14, 2014

Comment 18:

I've sent:
https://golang.org/cl/52090045
that fixes a very obscure data race in runtime. It can be potentially the cause of the
crashes you see. Difficult to say.

@dvyukov
Copy link
Member

dvyukov commented Jan 15, 2014

Comment 19:

https://golang.org/cl/52090045/
is submitted and it may fix the issue
I've tried to reproduce it several days on several machines, but reproduced only once
and w/o and special debugging output...

@gopherbot
Copy link
Author

Comment 20 by guohouzuo:

Thanks very much Dmitry. Shall I compile Go with the patch and try again?

@dvyukov
Copy link
Member

dvyukov commented Jan 16, 2014

Comment 21:

It would be great if you can confirm whether it's fixed or not.
The patch is already submitted, so you need to checkout tip version of Go and build.

@adg
Copy link
Contributor

adg commented Feb 13, 2014

Comment 22:

Status changed to WaitingForReply.

@gopherbot
Copy link
Author

Comment 23 by guohouzuo:

my apologize for the late reply. i shall compile go1.2 with the patch and give it a spin
this weekend.

@gopherbot
Copy link
Author

Comment 24 by guohouzuo:

Hello Dmitry.
Thanks very much for the fix! I compiled Go 1.2 with the patch, and ran the program 100
times in a loop, the bug has disappeared.

@dvyukov
Copy link
Member

dvyukov commented Feb 16, 2014

Comment 25:

Thanks!
Let's consider this as Fixed. If you spot this again (with tip or Go1.3) please notify
us.
Removing 1.2.1 label, because issue #5139 is marked as 1.2.1.

Labels changed: added release-go1.3, removed release-go1.2.1.

Status changed to Fixed.

@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
rsc added a commit that referenced this issue May 11, 2015
««« CL 52090045 / 302bdb5b08b1
runtime: fix data race in GC
Fixes #5139.
Update #7065.

R=golang-codereviews, bradfitz, minux.ma
CC=golang-codereviews
https://golang.org/cl/52090045
»»»

LGTM=r
R=golang-codereviews, r
CC=golang-dev
https://golang.org/cl/69790043
@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants