-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
possible GC-related panic #5554
Labels
Milestone
Comments
Ill try to bisect as I have the setup to run the juju tests. Owner changed to @davecheney. |
I can reproduce the problem (almost exactly the same panic message) at the original revision unexpected fault address 0xc200b00000 fatal error: fault [signal 0xb code=0x1 addr=0xc200b00000 pc=0x40e1a4] goroutine 3168 [running]: [fp=0xc2008d9608] runtime.throw(0xd05b37) /home/dfc/go/src/pkg/runtime/panic.c:473 +0x67 [fp=0xc2008d9620] runtime.sigpanic() /home/dfc/go/src/pkg/runtime/os_linux.c:239 +0xe7 [fp=0xc2008d99c0] scanblock(0x7f6031625000, 0x7f6031626488, 0xda, 0xc2008d9900) /home/dfc/go/src/pkg/runtime/mgc0.c:791 +0x534 [fp=0xc2008d9a10] markroot(0xc20011c000, 0x1000000028) /home/dfc/go/src/pkg/runtime/mgc0.c:1269 +0xab [fp=0xc2008d9a88] runtime.parfordo(0xc20011c000) /home/dfc/go/src/pkg/runtime/parfor.c:105 +0x9b [fp=0xc2008d9bb8] gc(0x7f603160520c) /home/dfc/go/src/pkg/runtime/mgc0.c:2000 +0x29d ----- stack segment boundary ----- [fp=0x7f6031605220] runtime.gc(0xc200000000) /home/dfc/go/src/pkg/runtime/mgc0.c:1927 +0x11b [fp=0x7f6031605278] runtime.mallocgc(0x480, 0x100000000, 0x0) /home/dfc/go/src/pkg/runtime/zmalloc_linux_amd64.c:101 +0x1e4 [fp=0x7f60316052b0] hash_grow(0x7e5d20, 0xc2008cf7c0) /home/dfc/go/src/pkg/runtime/hashmap.c:-203 +0x78 Status changed to Started. |
I've also confirmed that applying only 2c128d417029 to the release.go1.1 branch also fixes the crash, so I think it is safe to say as long as 2c128d417029/9557043 is applied for Go 1.1.1 we should be ok. @rogpeppe, the apiserver returns funcs which returns funcs doesn't it ? That was the original issue #5493 addressed. Labels changed: added priority-soon, go1.1.1, removed priority-triage. |
It still looks strange. I've tried to reproduce it, but failed. It either hangs or says: $ go test -v -gocheck.vv === RUN TestAll START: api_test.go:0: suite.SetUpSuite PASS: api_test.go:0: suite.SetUpSuite 0.000s START: api_test.go:828: suite.TestBadLogin START: api_test.go:0: suite.SetUpTest [LOG] 60.04749 INFO mongod: error command line: unknown option sslOnNormalPorts [LOG] 60.04754 INFO mongod: use --help for help $ mongod --version db version v2.4.3 Tue May 28 10:35:48.334 git version: fe1743177a5ea03e91e0052fb5e2cb2945f6d95f |
http://juju-dist.s3.amazonaws.com/tools/mongo-2.2.0-quantal-amd64.tgz. If you are not using a quantal series installation, don't worry it is compiled statically. It would be wise to uninstall mongod-2.4.3, unless you like 200hz timers preventing your machine from reaching a decent sleep state. |
Owner changed to @dvyukov. |
This issue was closed by revision 2f5825d. Status changed to Fixed. |
This CL also fixed a crash I was experiencing under freebsd/arm which I had not reported. Prior to this revision the freebsd builder process itself would crash with malloc/free deadlocks or other gc related 'cant happen' failures. Since rebuilding at tip the builder has run reliably for 12 hours. |
Oops, I spoke too soon, issue #5594. However stability is much improved after 5554 was closed, so 5594 is probably a unrelated crash. |
adg
added a commit
that referenced
this issue
May 11, 2015
««« CL 9831043 / e84e7204b01b runtime: fix heap corruption during GC The 'n' variable is used during rescan initiation in GC_END case, but it's overwritten with chan capacity in GC_CHAN case. As the result rescan is done with the wrong object size. Fixes #5554. R=golang-dev, khr CC=golang-dev https://golang.org/cl/9831043 »»» R=dvyukov, khr, dave CC=golang-dev https://golang.org/cl/10028044
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: