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

zeebo · 2016-08-17T22:57:40Z

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?
go version go1.7 darwin/amd64
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"
What did you do?
I ran this program: https://play.golang.org/p/LXVU7fsuOr
What did you expect to see?
A bunch of pointers forever.
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.

The text was updated successfully, but these errors were encountered:

bradfitz · 2016-08-17T23:09:03Z

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 · 2016-08-17T23:38:30Z

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 · 2016-08-17T23:48:23Z

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 · 2016-08-18T03:56:45Z

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 · 2016-08-18T15:55:06Z

#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 notifications@github.com
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 · 2016-10-25T13:08:24Z

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 · 2016-10-29T15:27:20Z

I'm having this issue after upgrade to go 1.7

RLH · 2016-10-29T19:13:07Z

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 notifications@github.com 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 · 2016-11-03T18:16:31Z

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 · 2016-11-03T20:09:11Z

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 · 2016-11-03T20:16:05Z

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 · 2016-11-03T20:39:20Z

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 · 2016-11-03T21:54:15Z

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:

runtime: nelems=32 nfree=28 nalloc=4 previous allocCount=2 freed=65534
fatal error: sweep increased allocation count
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
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x12002df08 pc=0x46e36d]

qrwteyrutiyoup · 2016-11-04T04:01:47Z

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

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.

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.
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 · 2016-11-04T04:04:51Z

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 · 2016-11-23T18:21:36Z

@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 · 2016-11-27T16:44:40Z

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 · 2017-01-20T08:46:36Z

@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 · 2017-02-07T01:06:55Z

@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.

bradfitz closed this as completed Aug 17, 2016

s-urbaniak mentioned this issue Aug 18, 2016

stage0: check for ftype=0 filesystem before overlay rkt/rkt#3052

Closed

4 tasks

psanford mentioned this issue Aug 22, 2016

Panics after upgrading to go1.7 gogo/protobuf#194

Closed

fmstephe mentioned this issue Sep 4, 2016

Remove use of unsafe package from spscq performance tests fmstephe/flib#3

Closed

fasheng mentioned this issue Sep 21, 2016

New crash in dde-daemon linuxdeepin/dde-daemon#31

Closed

bradfitz mentioned this issue Feb 10, 2017

runtime: fatal error: sweep increased allocation count (With go get) #19029

Closed

jwilder mentioned this issue Feb 13, 2017

fatal error: sweep increased allocation count since 1.2 influxdata/influxdb#7991

Closed

aykevl mentioned this issue Oct 2, 2017

Do not store Go pointers in C structs silvasur/golibrsync#4

Merged

golang locked and limited conversation to collaborators Feb 7, 2018

gopherbot added the FrozenDueToAge label Feb 7, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

zeebo commented Aug 17, 2016 •

edited by bradfitz

bradfitz commented Aug 17, 2016

zeebo commented Aug 17, 2016

zeebo commented Aug 17, 2016

randall77 commented Aug 18, 2016

RLH commented Aug 18, 2016

jpic commented Oct 25, 2016 •

edited

Icedroid commented Oct 29, 2016

RLH commented Oct 29, 2016

qrwteyrutiyoup commented Nov 3, 2016

RLH commented Nov 3, 2016

qrwteyrutiyoup commented Nov 3, 2016

RLH commented Nov 3, 2016

qrwteyrutiyoup commented Nov 3, 2016

qrwteyrutiyoup commented Nov 4, 2016

qrwteyrutiyoup commented Nov 4, 2016

zhulik commented Nov 23, 2016

jpic commented Nov 27, 2016 •

edited

dev-zero commented Jan 20, 2017

jpic commented Feb 7, 2017 •

edited

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

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

Comments

zeebo commented Aug 17, 2016 • edited by bradfitz

bradfitz commented Aug 17, 2016

zeebo commented Aug 17, 2016

zeebo commented Aug 17, 2016

randall77 commented Aug 18, 2016

RLH commented Aug 18, 2016

jpic commented Oct 25, 2016 • edited

Icedroid commented Oct 29, 2016

RLH commented Oct 29, 2016

qrwteyrutiyoup commented Nov 3, 2016

RLH commented Nov 3, 2016

qrwteyrutiyoup commented Nov 3, 2016

RLH commented Nov 3, 2016

qrwteyrutiyoup commented Nov 3, 2016

qrwteyrutiyoup commented Nov 4, 2016

qrwteyrutiyoup commented Nov 4, 2016

zhulik commented Nov 23, 2016

jpic commented Nov 27, 2016 • edited

dev-zero commented Jan 20, 2017

jpic commented Feb 7, 2017 • edited

zeebo commented Aug 17, 2016 •

edited by bradfitz

jpic commented Oct 25, 2016 •

edited

jpic commented Nov 27, 2016 •

edited

jpic commented Feb 7, 2017 •

edited