runtime: fatal error: sweep increased allocation count in go1.7

[zeebo]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   go version go1.7 darwin/amd64
2. What operating system and processor architecture are you using (go env)?
   GOARCH="amd64"
   GOBIN=""
   GOEXE=""
   GOHOSTARCH="amd64"
   GOHOSTOS="darwin"
   GOOS="darwin"
   GOPATH=""
   GORACE=""
   GOROOT="/Users/jeff/go"
   GOTOOLDIR="/Users/jeff/go/pkg/tool/darwin_amd64"
   CC="clang"
   GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tn/09dglcts0b9gc5111hnf0_dm0000gn/T/go-build421610542=/tmp/go-build -gno-record-gcc-switches -fno-common"
   CXX="clang++"
   CGO_ENABLED="1"
3. What did you do?
   I ran this program: https://play.golang.org/p/LXVU7fsuOr
4. What did you expect to see?
   A bunch of pointers forever.
5. What did you see instead?
   A bunch of pointers and then

runtime: nelems=512 nfree=510 nalloc=2 previous allocCount=1 nfreed=65535
fatal error: sweep increased allocation count

runtime stack:
runtime.throw(0xa934f, 0x20)
    /Users/jeff/go/src/runtime/panic.go:566 +0x95
runtime.(*mspan).sweep(0x1a42c0, 0x1a4201, 0x2cf01)
    /Users/jeff/go/src/runtime/mgcsweep.go:287 +0x7ab
runtime.(*mcentral).cacheSpan(0xfe450, 0x40002a201)
    /Users/jeff/go/src/runtime/mcentral.go:47 +0x491
runtime.(*mcache).refill(0x12f4b0, 0x2, 0xc420000b60)
    /Users/jeff/go/src/runtime/mcache.go:121 +0xae
runtime.(*mcache).nextFree.func1()
    /Users/jeff/go/src/runtime/malloc.go:505 +0x33
runtime.systemstack(0xc420019500)
    /Users/jeff/go/src/runtime/asm_amd64.s:298 +0x79
runtime.mstart()
    /Users/jeff/go/src/runtime/proc.go:1079

goroutine 1 [running]:
runtime.systemstack_switch()
    /Users/jeff/go/src/runtime/asm_amd64.s:252 fp=0xc42003f900 sp=0xc42003f8f8
runtime.(*mcache).nextFree(0x12f4b0, 0x2, 0x0, 0x0, 0x0)
    /Users/jeff/go/src/runtime/malloc.go:506 +0xb2 fp=0xc42003f958 sp=0xc42003f900
runtime.mallocgc(0x10, 0x0, 0xf300, 0xc42003fa20)
    /Users/jeff/go/src/runtime/malloc.go:658 +0x809 fp=0xc42003f9f8 sp=0xc42003f958
runtime.growslice(0x8b3c0, 0x0, 0x0, 0x0, 0xc, 0xc4203d2010, 0x0, 0x10)
    /Users/jeff/go/src/runtime/slice.go:126 +0x24e fp=0xc42003fa88 sp=0xc42003f9f8
fmt.(*fmt).pad(0xc4203de040, 0xc4203de0a0, 0xc, 0xc)
    /Users/jeff/go/src/fmt/format.go:92 +0x112 fp=0xc42003fb10 sp=0xc42003fa88
fmt.(*fmt).fmt_integer(0xc4203de040, 0xc4203dc010, 0x10, 0x0, 0xa6865, 0x11)
    /Users/jeff/go/src/fmt/format.go:307 +0x1f9 fp=0xc42003fb78 sp=0xc42003fb10
fmt.(*pp).fmt0x64(0xc4203de000, 0xc4203dc010, 0x1)
    /Users/jeff/go/src/fmt/print.go:348 +0x6c fp=0xc42003fbc0 sp=0xc42003fb78
fmt.(*pp).fmtPointer(0xc4203de000, 0x88ea0, 0xc4203dc010, 0x16, 0x70)
    /Users/jeff/go/src/fmt/print.go:515 +0xfc fp=0xc42003fc40 sp=0xc42003fbc0
fmt.(*pp).printArg(0xc4203de000, 0x88ea0, 0xc4203dc010, 0xc400000070)
    /Users/jeff/go/src/fmt/print.go:619 +0xec3 fp=0xc42003fd38 sp=0xc42003fc40
fmt.(*pp).doPrintf(0xc4203de000, 0xa54a5, 0x3, 0xc42003ff28, 0x1, 0x1)
    /Users/jeff/go/src/fmt/print.go:985 +0x123d fp=0xc42003fe20 sp=0xc42003fd38
fmt.Fprintf(0xf6140, 0xc42002c010, 0xa54a5, 0x3, 0xc42003ff28, 0x1, 0x1, 0xd, 0x0, 0x0)
    /Users/jeff/go/src/fmt/print.go:181 +0x76 fp=0xc42003fe88 sp=0xc42003fe20
fmt.Printf(0xa54a5, 0x3, 0xc42003ff28, 0x1, 0x1, 0x10, 0x0, 0x0)
    /Users/jeff/go/src/fmt/print.go:190 +0x72 fp=0xc42003fee8 sp=0xc42003fe88
main.main()
    /Users/jeff/tmp/bolt-bugs/foo.go:17 +0xb8 fp=0xc42003ff48 sp=0xc42003fee8
runtime.main()
    /Users/jeff/go/src/runtime/proc.go:183 +0x1f4 fp=0xc42003ffa0 sp=0xc42003ff48
runtime.goexit()
    /Users/jeff/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc42003ffa8 sp=0xc42003ffa0
exit status 2

I'm aware this program is doing something silly by constructing a pointer to a field that isn't backed by any allocation, but it didn't crash on go1.6 and I'm not sure if there's any defined behavior around this. If the answer is "don't do that then. you're in wacky land because of unsafe", that's fine, I just want to be sure that this isn't a problem. I found it interesting that it took many prints for it to fail, rather than failing right away.

[bradfitz]

Yeah, "don't do that then. you're in wacky land because of unsafe"

The rules around unsafe, cgo, etc to be nice to the increasingly-capable GC are getting stricter with each release.

If you run it with GOGC=1 it'll crash even sooner.

[zeebo]

Ok so for clarity, you are no longer allowed to create/inspect pointer values that aren't pointing at valid Go allocated memory anymore? I'm not referring to dereferencing them, that was always in wacko land, just handling them.

[zeebo]

Seems like the documentation at https://golang.org/pkg/unsafe/ specifically says this is invalid under bullet point (3), so I'll consider this fully answered. Thanks.

[randall77]

Whether they point to Go allocated memory or not is irrelevant. You have always been able (and continue to be able) to have Go pointers point to differently allocated memory (globals, cgo-allocated stuff, syscall.Mmap, etc.). What's currently newly breaking in go 1.7 is pointer arithmetic on pointers that point to no memory, i.e. faulting pages.
I'm thinking about maybe fixing this in some way. See my comment in #16772

[RLH]

#16772 #16772 is about pointers
causing page faults. The problem here is that there is a pointer to some
place in the Go heap where the GC didn't allocate an object. The GC doesn't
understand what is going on but it knows its internal data structures
aren't fully prepared to deal with such a situation. The difference in
between 1.6 and 1.7 is that the 1.7 GC is now smart enough to detect the
bug and report that it has found a reference to an object that it didn't
allocate.

Expect the GC to continue to get better at spotting and reporting these
kinds of bugs. Think of using unsafe as purchasing technical debt lottery
ticket.

On Wed, Aug 17, 2016 at 11:56 PM, Keith Randall [email protected]
wrote:

Whether they point to Go allocated memory or not is irrelevant. You have
always been able (and continue to be able) to have Go pointers point to
differently allocated memory (globals, cgo-allocated stuff, syscall.Mmap,
etc.). What's currently newly breaking in go 1.7 is pointer arithmetic on
pointers that point to no memory, i.e. faulting pages.
I'm thinking about maybe fixing this in some way. See my comment in #16772
#16772

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16778 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7Wn2Jw5MyXF3_HWR0QMCZWElJeoPlGks5qg9gKgaJpZM4Jm-NY
.

[jpic]

I'm having this issue with all go packages on arch linux, I notice because every time i google the error i land on this issue, with go package version: 2:1.7.3-1 I don't have any kind of MAC or RBAC such as SELinux enabled.

Could someone perhaps post a example "bad code" and how to fix it, for non-golang-specialists ? That would be super nice 🎸

Edit: I ran the same program again and it didn't crash.

[Icedroid]

I'm having this issue after upgrade to go 1.7

[RLH]

It would be great if you could create a reproducer. Next confirm it doesn't
have any races. Finally take a close look at and/or eliminate any uses of
unsafe. If that doesn't reveal the problem then I'd post the reproducer
here.

Without a reproducer or some more clues this is not really actionable.

On Sat, Oct 29, 2016 at 11:27 AM, Icecream [email protected] wrote:

I'm having this issue after upgrade to go 1.7

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16778 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7Wn91UeSQgmPMKhHOIiPBHrK1YZ_2Nks5q42XkgaJpZM4Jm-NY
.

[qrwteyrutiyoup]

I seem to have a similar issue with 1.7.3 linux/amd64.

In my case, I was porting a perl script to go and ended up with something like https://gist.github.com/qrwteyrutiyoup/97adfd0a26f155317df7354351a35475

Problem #1 was during "go build". Sometimes it would work OK, some other times it would throw errors like https://gist.github.com/qrwteyrutiyoup/1a74373eb24667f06031df79151c86d4

Problem #2 was running the generated program itself. Sometimes it would work OK, and some other times, throw errors like these: https://gist.github.com/qrwteyrutiyoup/5c1746150aa5fa26b83f8b1ca9d44e67 (similiar to the previous one)

To test the program, you can use this test file https://www.uece.net/misc/test-file.txt.xz (compressed due to size; ~32MB uncompressed; about 1.1M compressed), passing it as argument to the program.

Expected output:
sent: 487069#received: 6528#delivery ratio: 0.013403#average end-to-end-delay: 245.269324 milliseconds#throughput: 0.511456 Mbps#routing overhead: 162.766391#

Let me know if I can provide additional info to debug the issue (or if I am doing something silly in the code itself)

[RLH]

Thanks for the replicator.

Unfortunately, the replicator reliable produces the expected output on my laptop. I have not been able to reproduce the reported error. I will leave it running overnight.

Perhaps your machine has many more HW threads than mine. Could you try and reproduce it with GOMAXPROCS=4?

[qrwteyrutiyoup]

Thanks for checking it out. It did reproduce here, although not as reliably, indeed.

Try to put it in an infinite loop and it crashes more quickly:
while /bin/true; do ./m test-file.txt; done

I tried this in loop (both for go build and the program execution itself, and it started crashing in go 1.5.x (which is when the compiler started to be written in go?). Go 1.4 doesn't crash at all, loop or no loop. Tested with the binary distributions available for download on the Go website.

[RLH]

Interesting. I am using the 1.7.3 binary from golang.org and I've been running it in the loop as you suggested. I've also tried GOGC=1 without a failure. I'll keep at it.

[qrwteyrutiyoup]

Oh, I see. I was using 1.7.3 from ArchLinux; the older versions I was using from golang.org, but I just checked with the 1.7.3 binary from there and got the same result.

Starting to look like something specific to this computer, but it's odd that it works fine with Go 1.4.3.
Please let me know if you have any suggestions to help track down the issue.

My current version of the sample program I posted still crashes in 1.7.3 (and not in 1.4.3), but interestingly, it gave me already 3 different crashes:

1. runtime: nelems=32 nfree=28 nalloc=4 previous allocCount=2 freed=65534
   fatal error: sweep increased allocation count

2. runtime: gp: gp=0x52fdd8, goid=140726032847992, gp->atomicstatus=1429394552
   runtime: g: g=0xc420001a00, goid=5, g->atomicstatus=2
   fatal error: bad g->status in ready

3. fatal error: unexpected signal during runtime execution
   [signal SIGSEGV: segmentation violation code=0x1 addr=0x12002df08 pc=0x46e36d]

[qrwteyrutiyoup]

OK, I did some more testing and probably found the culprit. Here's the findings:

1. I tested with different distros (CentOS 7, Debian 8, Fedora 24 and Ubuntu 16.10), without being able to reproduce the issue.

Interestingly, it crashed in my 2 ArchLinux boxes, a desktop and a laptop. After checking out what could be different in such systems, I realized I was using a -ck kernel (https://wiki.archlinux.org/index.php/linux-ck). I returned to a "stock" kernel (4.8.6-1-ARCH) and was unable to reproduce the issue since then.

2. Not sure how relevant this is, but while debugging in my box with the -ck kernel, I found out that if I had "GODEBUG=gcstoptheworld=1,gcshrinkstackoff=1" (which I got from as a suggestion from some other issue -- runtime: bad pointer in unexpected span #12138 -- the crash did not occur, or at least not as quickly; it's real quick to trigger, in general.

3. As I said earlier, I was unable to reproduce it (still with the -ck kernel) with Go 1.4.3 , but 1.5.4 triggered it; this made me think that was some side effect of the change in the compiler, that started to be written in Go from 1.5.x, if I recall correctly.

So, I am not sure this is an issue that should be documented/investigated, or if it's a problem with the kernel itself, but for now I am good, on a different kernel.

[qrwteyrutiyoup]

And I may have pulled the trigger too quickly, as I just noted the other computer which reproduced the problem had vanilla kernel 4.8.0-gc8d2bc9 on it. I can't change its kernel right now, but tomorrow I will give it a try with the same version I have on the laptop now, to see if it the crash goes away.

[zhulik]

@qrwteyrutiyoup thanks! I have two ArchLinux boxes with -ck kernel and your comment really brings my a hope=) go compiler and syncthing is broken. I will try to use stock

[jpic]

Still reproducible on 4.8.7, but works on vanilla 4.8.10 on Arch Linux thanks a heap !!

However, 4.8.10 doesn't have CONFIG_USER_NS, building a 4.8.10 with it and will report back if it reproduces

Kudos to @qrwteyrutiyoup for the epic investigation logs 🎸

[dev-zero]

@jpic did you try with CONFIG_USER_NS and can confirm that this was the issue?
I am running Gentoo Linux using Kernel 4.9.4 (without any fancy patches, but self-configured and built, stable with everything else) and go-1.7.4 and experience similar spurious errors as described here when trying to bootstrap go, build docker or build the test programs supplied here:

---> Making bundle: dynbinary (in bundles/1.13.0-rc7/dynbinary)
Building: bundles/1.13.0-rc7/dynbinary-client/docker-1.13.0-rc7
Created binary: bundles/1.13.0-rc7/dynbinary-client/docker-1.13.0-rc7
Building: bundles/1.13.0-rc7/dynbinary-daemon/dockerd-1.13.0-rc7
# github.com/docker/docker/cmd/dockerd
unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x4c38be]

goroutine 1 [running]:
runtime.throw(0x5cb8e4, 0x5)
	/usr/lib/go/src/runtime/panic.go:566 +0x95 fp=0xc420063800 sp=0xc4200637e0
runtime.sigpanic()
	/usr/lib/go/src/runtime/sigpanic_unix.go:27 +0x288 fp=0xc420063858 sp=0xc420063800
cmd/link/internal/ld.(*deadcodepass).flood(0xc420063cd0)
	/usr/lib/go/src/cmd/link/internal/ld/deadcode.go:271 +0xfe fp=0xc420063af0 sp=0xc420063858
cmd/link/internal/ld.deadcode(0xc4204be000)
	/usr/lib/go/src/cmd/link/internal/ld/deadcode.go:60 +0xe1 fp=0xc420063d28 sp=0xc420063af0
cmd/link/internal/ld.Ldmain()
	/usr/lib/go/src/cmd/link/internal/ld/pobj.go:192 +0x1089 fp=0xc420063eb0 sp=0xc420063d28
cmd/link/internal/amd64.Main()
	/usr/lib/go/src/cmd/link/internal/amd64/obj.go:45 +0x19 fp=0xc420063eb8 sp=0xc420063eb0
main.main()
	/usr/lib/go/src/cmd/link/main.go:28 +0x27d fp=0xc420063f48 sp=0xc420063eb8
runtime.main()
	/usr/lib/go/src/runtime/proc.go:183 +0x1f4 fp=0xc420063fa0 sp=0xc420063f48
runtime.goexit()
	/usr/lib/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc420063fa8 sp=0xc420063fa0

[jpic]

@jpic did you try with CONFIG_USER_NS and can confirm that this was the issue?

I have it enabled right now on a 4.9.6-1-userns kernel and I'm experiencing fatal error: sweep increased allocation count this time with the acbuild write command:

$ sudo acbuild write mez-0.0.1-linux-amd64.aci
runtime: nelems=128 nfree=39 nalloc=89 previous allocCount=87 nfreed=65534
fatal error: sweep increased allocation count

runtime stack:
runtime.throw(0x882a3b, 0x20)
	/usr/lib/go/src/runtime/panic.go:566 +0x95
runtime.(*mspan).sweep(0x7fcd3cc10640, 0xd00000000, 0xc400000001)
	/usr/lib/go/src/runtime/mgcsweep.go:287 +0x7ab
runtime.sweepone(0x4403a6)
	/usr/lib/go/src/runtime/mgcsweep.go:112 +0xfe
runtime.gosweepone.func1()
	/usr/lib/go/src/runtime/mgcsweep.go:124 +0x2b
runtime.systemstack(0xc420020a00)
	/usr/lib/go/src/runtime/asm_amd64.s:298 +0x79
runtime.mstart()
	/usr/lib/go/src/runtime/proc.go:1079

goroutine 3 [running]:
runtime.systemstack_switch()
	/usr/lib/go/src/runtime/asm_amd64.s:252 fp=0xc42002af48 sp=0xc42002af40
runtime.gosweepone(0x0)
	/usr/lib/go/src/runtime/mgcsweep.go:125 +0x4a fp=0xc42002af78 sp=0xc42002af48
runtime.bgsweep(0xc42005a000)
	/usr/lib/go/src/runtime/mgcsweep.go:66 +0xbb fp=0xc42002afb8 sp=0xc42002af78
runtime.goexit()
	/usr/lib/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc42002afc0 sp=0xc42002afb8
created by runtime.gcenable
	/usr/lib/go/src/runtime/mgc.go:195 +0x61

goroutine 1 [runnable]:
compress/flate.(*compressor).findMatch(0xc420342000, 0xd337, 0xd245, 0x3, 0xac9, 0x102, 0x3efe, 0x300000001)
	/usr/lib/go/src/compress/flate/deflate.go:229
compress/flate.(*compressor).deflate(0xc420342000)
	/usr/lib/go/src/compress/flate/deflate.go:438 +0xa0d
compress/flate.(*compressor).write(0xc420342000, 0xc42064a000, 0x41f8, 0x8000, 0x8000, 0x17b48bf8, 0x0)
	/usr/lib/go/src/compress/flate/deflate.go:546 +0x76
compress/flate.(*Writer).Write(0xc420342000, 0xc42064a000, 0x41f8, 0x8000, 0x8000, 0x17b48bf8, 0x0)
	/usr/lib/go/src/compress/flate/deflate.go:702 +0x4b
compress/gzip.(*Writer).Write(0xc42033e000, 0xc42064a000, 0x41f8, 0x8000, 0x41f8, 0x0, 0x0)
	/usr/lib/go/src/compress/gzip/gzip.go:195 +0xc9
archive/tar.(*Writer).Write(0xc420340000, 0xc42064a000, 0x41f8, 0x8000, 0x41f8, 0x0, 0x0)
	/usr/lib/go/src/archive/tar/writer.go:372 +0x83
io.copyBuffer(0xa70ac0, 0xc420340000, 0xa71c00, 0xc4202e2260, 0xc42064a000, 0x8000, 0x8000, 0x7d3c01, 0x0, 0x0)
	/usr/lib/go/src/io/io.go:392 +0x260
io.Copy(0xa70ac0, 0xc420340000, 0xa71c00, 0xc4202e2260, 0x2, 0x2, 0xc4200127d0)
	/usr/lib/go/src/io/io.go:360 +0x68
github.com/appc/acbuild/vendor/github.com/appc/spec/aci.(*imageArchiveWriter).AddFile(0xc4202eaf30, 0xc420127ad0, 0xa71c00, 0xc4202e2260, 0xc420127ad0, 0x0)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/vendor/github.com/appc/spec/aci/writer.go:58 +0x9d
github.com/appc/acbuild/vendor/github.com/appc/spec/aci.BuildWalker.func1(0xc42009d3b0, 0x4a, 0xa78920, 0xc420127a00, 0x0, 0x0, 0x0, 0x0)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/vendor/github.com/appc/spec/aci/build.go:104 +0x252
path/filepath.walk(0xc42009d3b0, 0x4a, 0xa78920, 0xc420127a00, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:351 +0x81
path/filepath.walk(0xc42001b480, 0x33, 0xa78920, 0xc4202f9450, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc420167bc0, 0x2f, 0xa78920, 0xc4202f8f70, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc420167aa0, 0x29, 0xa78920, 0xc4202f8b60, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc4202ed560, 0x22, 0xa78920, 0xc4202f9ad0, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc4202f12e0, 0x1e, 0xa78920, 0xc4202f9790, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc4202f1220, 0x1a, 0xa78920, 0xc4202f9520, 0xc4202e6900, 0x0, 0x0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.walk(0xc4202f0960, 0x13, 0xa78920, 0xc4202f9380, 0xc4202e6900, 0x0, 0xc4202ed3b0)
	/usr/lib/go/src/path/filepath/path.go:376 +0x344
path/filepath.Walk(0xc4202f0960, 0x13, 0xc4202e6900, 0xc4202eaf30, 0x0)
	/usr/lib/go/src/path/filepath/path.go:398 +0xd5
github.com/appc/acbuild/lib.(*ACBuild).Write(0xc4202f6180, 0x7ffdeb637612, 0x19, 0x0, 0xc4202ea7a0, 0x0, 0x0, 0x0, 0x0)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/lib/write.go:95 +0x420
main.runWrite(0xa98080, 0xc4202ea7a0, 0x1, 0x1, 0x5)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/acbuild/write.go:50 +0xd8
main.runWrapper.func1(0xa98080, 0xc4202ea7a0, 0x1, 0x1)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/acbuild/acbuild.go:131 +0x86
github.com/appc/acbuild/vendor/github.com/spf13/cobra.(*Command).execute(0xa98080, 0xc4202ea740, 0x1, 0x1, 0xa98080, 0xc4202ea740)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/vendor/github.com/spf13/cobra/command.go:565 +0x411
github.com/appc/acbuild/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xa93280, 0x0, 0x0, 0x0)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/vendor/github.com/spf13/cobra/command.go:651 +0x367
github.com/appc/acbuild/vendor/github.com/spf13/cobra.(*Command).Execute(0xa93280, 0xe, 0x8b0360)
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/vendor/github.com/spf13/cobra/command.go:610 +0x2b
main.main()
	/build/acbuild/src/acbuild-0.4.0/gopath/src/github.com/appc/acbuild/acbuild/acbuild.go:268 +0xbc

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/usr/lib/go/src/runtime/asm_amd64.s:2086 +0x1

I don't think that's really a golang bug though, looks like an acbuild/cobra bug.