runtime: send on channel panics with "unexpected signal during runtime execution"

[mappu]

What version of Go are you using (go version)?

go version go1.8 windows/amd64
x86_64-w64-mingw32-gcc (GCC) 5.4.0

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\repos\winio-zstd-panic-clone
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\cygwin\tmp\go-build164083627=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
set PKG_CONFIG=pkg-config
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2

What did you do?

1. Have a working Go + CGO environment on Windows (here i use mingw-w64).

2. Install test case: go get github.com/mappu/winio-zstd-panic/src/winio-zstd-panic

3. Run a few times: $GOPATH/bin/winio-zstd-panic - the bug happens maybe 1/10 executions on my machine (Intel i5 6400).

What did you expect to see?

******************************
client: making connection...

client: connected

server: recieved signal, shutting down

What did you see instead?

******************************
client: making connection...
fatal error:
client: connected
unexpected signal during runtime execution
[signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0x40e395]

goroutine 18 [running]:
runtime.throw(0x4fd587, 0x2a)
        C:/Go/src/runtime/panic.go:596 +0x9c fp=0xc042083e08 sp=0xc042083de8
runtime.sigpanic()
        C:/Go/src/runtime/signal_windows.go:155 +0x18b fp=0xc042083e38 sp=0xc042083e08
runtime.lock(0x24749f73771afe8f)
        C:/Go/src/runtime/lock_sema.go:43 +0x65 fp=0xc042083e70 sp=0xc042083e38
runtime.chansend(0x4cf380, 0x24749f73771afe37, 0xc042083fb0, 0xc042083f01, 0x4b64fa, 0xc042083f9c)
        C:/Go/src/runtime/chan.go:176 +0xba fp=0xc042083f20 sp=0xc042083e70
runtime.chansend1(0x4cf380, 0x24749f73771afe37, 0xc042083fb0)
        C:/Go/src/runtime/chan.go:113 +0x4d fp=0xc042083f60 sp=0xc042083f20
github.com/Microsoft/go-winio.ioCompletionProcessor(0x1c8)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:133 +0xea fp=0xc042083fd8 sp=0xc042083f60
runtime.goexit()
        C:/Go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc042083fe0 sp=0xc042083fd8
created by github.com/Microsoft/go-winio.initIo
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:57 +0x87

goroutine 1 [runnable]:
main.main()
        C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:112 +0xcd

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        C:/Go/src/runtime/asm_amd64.s:2197 +0x1

goroutine 5 [select]:
github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine(0xc042030070)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:269 +0x4e9
created by github.com/Microsoft/go-winio.ListenPipe
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:352 +0x2ec

goroutine 6 [chan receive]:
github.com/Microsoft/go-winio.(*win32PipeListener).Accept(0xc042030070, 0x0, 0x0, 0x0, 0x0)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:373 +0x120
main.(*Terminator).worker(0xc04200c400)
        C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:39 +0x3a
created by main.NewTerminator
        C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:34 +0x141

goroutine 19 [chan receive]:
github.com/Microsoft/go-winio.(*win32File).asyncIo(0xc042074050, 0xc042078060, 0x0, 0xc000000000, 0x0, 0x0, 0x5bc4a0, 0xc042088000, 0x0, 0x0, ...)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:167 +0x24d
github.com/Microsoft/go-winio.connectPipe(0xc042074050, 0x0, 0x0)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:362 +0xc1
github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine.func1(0xc042072060, 0xc042076000)
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:267 +0x35
created by github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine
        C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:268 +0x286

goroutine 20 [runnable, locked to thread]:
syscall.Syscall(0x7ffb78294620, 0x1, 0x1cc, 0x0, 0x0, 0xc04216e080, 0xc042019900, 0x2)
        C:/Go/src/runtime/syscall_windows.go:163 +0x6b
syscall.GetFileType(0x1cc, 0x428ea5, 0xc000000008, 0xc04216e080)
        C:/Go/src/syscall/zsyscall_windows.go:756 +0x6b
syscall.Seek(0x1cc, 0x0, 0x1, 0x1001, 0x101000000001000, 0x0)
        C:/Go/src/syscall/syscall_windows.go:349 +0x57
os.(*File).pread(0xc042076008, 0xc042280000, 0x1000, 0x1000, 0x0, 0x0, 0x0, 0x0)
        C:/Go/src/os/file_windows.go:298 +0xc8
os.(*File).ReadAt(0xc042076008, 0xc042280000, 0x1000, 0x1000, 0x0, 0x1000, 0xc042276c00, 0x929)
        C:/Go/src/os/file.go:120 +0xba
main.start_workload_simulator.func1(0xc042072120)
        C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:78 +0x10e
created by main.start_workload_simulator
        C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:93 +0x46

This test case creates a win32 named pipe; performs some background work; and then connects to the named pipe. But for some reason, connecting to the named pipe causes a panic within Golang's channel / signal handling.

This test case depends on both (A) a third-party Windows library, and (B) a third-party CGO library. I did report this issue to the vendor of A as microsoft/go-winio#41 but, the more i look at the panic trace, i think the issue is with Golang's runtime (apologies in advance if that's wrong).

[davecheney]

Almost certainly a data race. Have you tested your application with the race detector.

…

On Thu, 9 Mar 2017, 12:55 mappu ***@***.***> wrote: What version of Go are you using (go version)? go version go1.8 windows/amd64 x86_64-w64-mingw32-gcc (GCC) 5.4.0 What operating system and processor architecture are you using (go env)? set GOARCH=amd64 set GOBIN= set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOOS=windows set GOPATH=C:\repos\winio-zstd-panic-clone set GORACE= set GOROOT=C:\Go set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set CC=gcc set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\cygwin\tmp\go-build164083627=/tmp/go-build -gno-record-gcc-switches set CXX=g++ set CGO_ENABLED=1 set PKG_CONFIG=pkg-config set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 What did you do? 1. Have a working Go + CGO environment on Windows (here i use mingw-w64). 2. Install test case: go get github.com/mappu/winio-zstd-panic/src/winio-zstd-panic 3. Run a few times: $GOPATH/bin/winio-zstd-panic - the bug happens maybe 1/10 executions on my machine (Intel i5 6400). What did you expect to see? ****************************** client: making connection... client: connected server: recieved signal, shutting down What did you see instead? ****************************** client: making connection... fatal error: client: connected unexpected signal during runtime execution [signal 0xc0000005 code=0x0 addr=0xffffffffffffffff pc=0x40e395] goroutine 18 [running]: runtime.throw(0x4fd587, 0x2a) C:/Go/src/runtime/panic.go:596 +0x9c fp=0xc042083e08 sp=0xc042083de8 runtime.sigpanic() C:/Go/src/runtime/signal_windows.go:155 +0x18b fp=0xc042083e38 sp=0xc042083e08 runtime.lock(0x24749f73771afe8f) C:/Go/src/runtime/lock_sema.go:43 +0x65 fp=0xc042083e70 sp=0xc042083e38 runtime.chansend(0x4cf380, 0x24749f73771afe37, 0xc042083fb0, 0xc042083f01, 0x4b64fa, 0xc042083f9c) C:/Go/src/runtime/chan.go:176 +0xba fp=0xc042083f20 sp=0xc042083e70 runtime.chansend1(0x4cf380, 0x24749f73771afe37, 0xc042083fb0) C:/Go/src/runtime/chan.go:113 +0x4d fp=0xc042083f60 sp=0xc042083f20github.com/Microsoft/go-winio.ioCompletionProcessor(0x1c8) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:133 +0xea fp=0xc042083fd8 sp=0xc042083f60 runtime.goexit() C:/Go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc042083fe0 sp=0xc042083fd8 created by github.com/Microsoft/go-winio.initIo C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:57 +0x87 goroutine 1 [runnable]: main.main() C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:112 +0xcd goroutine 17 [syscall, locked to thread]: runtime.goexit() C:/Go/src/runtime/asm_amd64.s:2197 +0x1 goroutine 5 [select]:github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine(0xc042030070) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:269 +0x4e9 created by github.com/Microsoft/go-winio.ListenPipe C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:352 +0x2ec goroutine 6 [chan receive]:github.com/Microsoft/go-winio.(*win32PipeListener).Accept(0xc042030070, 0x0, 0x0, 0x0, 0x0) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:373 +0x120 main.(*Terminator).worker(0xc04200c400) C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:39 +0x3a created by main.NewTerminator C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:34 +0x141 goroutine 19 [chan receive]:github.com/Microsoft/go-winio.(*win32File).asyncIo(0xc042074050, 0xc042078060, 0x0, 0xc000000000, 0x0, 0x0, 0x5bc4a0, 0xc042088000, 0x0, 0x0, ...) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/file.go:167 +0x24dgithub.com/Microsoft/go-winio.connectPipe(0xc042074050, 0x0, 0x0) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:362 +0xc1github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine.func1(0xc042072060, 0xc042076000) C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:267 +0x35 created by github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine C:/repos/winio-zstd-panic/src/github.com/Microsoft/go-winio/pipe.go:268 +0x286 goroutine 20 [runnable, locked to thread]: syscall.Syscall(0x7ffb78294620, 0x1, 0x1cc, 0x0, 0x0, 0xc04216e080, 0xc042019900, 0x2) C:/Go/src/runtime/syscall_windows.go:163 +0x6b syscall.GetFileType(0x1cc, 0x428ea5, 0xc000000008, 0xc04216e080) C:/Go/src/syscall/zsyscall_windows.go:756 +0x6b syscall.Seek(0x1cc, 0x0, 0x1, 0x1001, 0x101000000001000, 0x0) C:/Go/src/syscall/syscall_windows.go:349 +0x57 os.(*File).pread(0xc042076008, 0xc042280000, 0x1000, 0x1000, 0x0, 0x0, 0x0, 0x0) C:/Go/src/os/file_windows.go:298 +0xc8 os.(*File).ReadAt(0xc042076008, 0xc042280000, 0x1000, 0x1000, 0x0, 0x1000, 0xc042276c00, 0x929) C:/Go/src/os/file.go:120 +0xba main.start_workload_simulator.func1(0xc042072120) C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:78 +0x10e created by main.start_workload_simulator C:/repos/winio-zstd-panic/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:93 +0x46 This test case creates a win32 named pipe; performs some background work; and then connects to the named pipe. But for some reason, connecting to the named pipe causes a panic within Golang's channel / signal handling. This test case depends on both (A) a third-party Windows library, and (B) a third-party CGO library. I did report this issue to the vendor of A as microsoft/go-winio#41 <microsoft/go-winio#41> but, the more i look at the panic trace, i think the issue is with Golang's runtime (apologies in advance if that's wrong). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19468>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAxKrrjock7p423m4Hi-ZzlzkSZJQks5rj1wbgaJpZM4MXjK3> .

[mappu]

I built the test application under -race, and it ran 1000 times without triggering the panic.

I think i needed to make the failure more reliable, so i thought about ways to do that.

I decided to set GOMAXPROCS=1. Still have not seen any race-detection warning, but, very quickly I got this different panic:

******************************
client: making connection...

client: connected
**runtime: nelems=170 nfree=102 nalloc=68 previous allocCount=67 nfreed=65535
fatal error: sweep increased allocation count

runtime stack:
runtime.throw(0x53ca9d, 0x20)
        C:/Go/src/runtime/panic.go:596 +0x9c
runtime.(*mspan).sweep(0x14c51d0, 0x14c5100, 0x40001d800000000)
        C:/Go/src/runtime/mgcsweep.go:288 +0x8e9
runtime.sweepone(0x0)
        C:/Go/src/runtime/mgcsweep.go:110 +0x1bb
runtime.(*mheap).reclaim(0x66e6c0, 0x1)
        C:/Go/src/runtime/mheap.go:522 +0x167
runtime.(*mheap).alloc_m(0x66e6c0, 0x1, 0x2b, 0x0)
        C:/Go/src/runtime/mheap.go:553 +0x2c1
runtime.(*mheap).alloc.func1()
        C:/Go/src/runtime/mheap.go:627 +0x52
runtime.systemstack(0x3bbfcf0)
        C:/Go/src/runtime/asm_amd64.s:343 +0xb5
runtime.(*mheap).alloc(0x66e6c0, 0x1, 0x1000000002b, 0x0)
        C:/Go/src/runtime/mheap.go:628 +0xa7
runtime.(*mcentral).grow(0x670cc0, 0x0)
        C:/Go/src/runtime/mcentral.go:212 +0x95
runtime.(*mcentral).cacheSpan(0x670cc0, 0xc042023860)
        C:/Go/src/runtime/mcentral.go:93 +0x131
runtime.(*mcache).refill(0x14c0000, 0x2b, 0x0)
        C:/Go/src/runtime/mcache.go:122 +0xae
runtime.(*mcache).nextFree.func1()
        C:/Go/src/runtime/malloc.go:526 +0x39
runtime.systemstack(0xc04201c000)
        C:/Go/src/runtime/asm_amd64.s:327 +0x7e
runtime.mstart()
        C:/Go/src/runtime/proc.go:1132

goroutine 10 [running]:
runtime.systemstack_switch()
        C:/Go/src/runtime/asm_amd64.s:281 fp=0xc042077dc8 sp=0xc042077dc0
runtime.(*mcache).nextFree(0x14c0000, 0x2b, 0xc04200e480, 0xc042077f78, 0x404cf0)
        C:/Go/src/runtime/malloc.go:527 +0xc0 fp=0xc042077e28 sp=0xc042077dc8
runtime.mallocgc(0x1000, 0x510020, 0x50ee01, 0xc04200e480)
        C:/Go/src/runtime/malloc.go:679 +0x6c6 fp=0xc042077ed0 sp=0xc042077e28
runtime.makeslice(0x510020, 0x1000, 0x1000, 0xc042317000, 0x1000, 0x1000)
        C:/Go/src/runtime/slice.go:54 +0x83 fp=0xc042077f20 sp=0xc042077ed0
main.start_workload_simulator.func1(0xc04200e480)
        C:/repos/winio-zstd-panic-clone/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:77 +0x105 fp=0xc042077fd8 sp=0xc042077f20
runtime.goexit()
        C:/Go/src/runtime/asm_amd64.s:2197 +0x1 fp=0xc042077fe0 sp=0xc042077fd8
created by main.start_workload_simulator
        C:/repos/winio-zstd-panic-clone/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:93 +0x54

goroutine 1 [runnable]:
main.main()
        C:/repos/winio-zstd-panic-clone/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:112 +0xde

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        C:/Go/src/runtime/asm_amd64.s:2197 +0x1

goroutine 5 [select]:
github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine(0xc042012150)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:269 +0x66d
created by github.com/Microsoft/go-winio.ListenPipe
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:352 +0x3e0

goroutine 6 [chan receive]:
github.com/Microsoft/go-winio.(*win32PipeListener).Accept(0xc042012150, 0x0, 0x0, 0x0, 0x0)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:373 +0x178
main.(*Terminator).worker(0xc04200c440)
        C:/repos/winio-zstd-panic-clone/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:39 +0x5d
created by main.NewTerminator
        C:/repos/winio-zstd-panic-clone/src/github.com/mappu/winio-zstd-panic/src/winio-zstd-panic/main.go:34 +0x19c

goroutine 8 [runnable, locked to thread]:
syscall.Syscall6(0x7ffb78286bf0, 0x5, 0x1b0, 0xc04206bf8c, 0xc04206bf90, 0xc04206bf98, 0xffffffff, 0x0, 0x4f68a9, 0x7ffb72c13040, ...)
        C:/Go/src/runtime/syscall_windows.go:174 +0x8a
github.com/Microsoft/go-winio.getQueuedCompletionStatus(0x1b0, 0xc04206bf8c, 0xc04206bf90, 0xc04206bf98, 0xffffffff, 0x0, 0x0)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/zsyscall_windows.go:76 +0xf3
github.com/Microsoft/go-winio.ioCompletionProcessor(0x1b0)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/file.go:129 +0x99
created by github.com/Microsoft/go-winio.initIo
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/file.go:57 +0xb9

goroutine 9 [chan receive]:
github.com/Microsoft/go-winio.(*win32File).asyncIo(0xc042018280, 0xc042066d80, 0x0, 0xc000000000, 0x0, 0x0, 0x6424a0, 0xc042008500, 0x0, 0x0, ...)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/file.go:167 +0x373
github.com/Microsoft/go-winio.connectPipe(0xc042018280, 0x0, 0x0)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:362 +0xfb
github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine.func1(0xc04200e3c0, 0xc042004038)
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:267 +0x58
created by github.com/Microsoft/go-winio.(*win32PipeListener).listenerRoutine
        C:/repos/winio-zstd-panic-clone/src/github.com/Microsoft/go-winio/pipe.go:268 +0x35d

[mappu]

I tried 1.7.5, it seems immune from this issue.

Go version	GOMAXPROCS	-race	Panic
go 1.8.0	GOMAXPROCS=4	no race	Crashed in 35/100 of runs (first panic in this thread) unexpected signal during runtime execution
go 1.8.0	GOMAXPROCS=1	no race	Crashed in 42/100 runs (second panic in this thread) sweep increased allocation count
go 1.8.0	GOMAXPROCS=4	-race	No crash
go 1.8.0	GOMAXPROCS=1	-race	Crashed in 43/100 runs (second panic in this thread) sweep increased allocation count
go 1.7.5	GOMAXPROCS=4	no race	No crash
go 1.7.5	GOMAXPROCS=1	no race	No crash
go 1.7.5	GOMAXPROCS=4	-race	No crash
go 1.7.5	GOMAXPROCS=1	-race	No crash
go 1.6.4	GOMAXPROCS=4	no race	No crash
go 1.6.4	GOMAXPROCS=1	no race	No crash
go 1.6.4	GOMAXPROCS=4	-race	No crash
go 1.6.4	GOMAXPROCS=1	-race	No crash

UPDATE: added crash statistics; added 1.6.4 results; noticed failure in go1.8.0 no-race 1-proc under more rigorous test script

[ianlancetaylor]

Next guess would be memory corruption from your cgo code. Certainly memory has gotten corrupted somehow. You might want to try running with GODEBUG=cgocheck=2, although that won't catch cases where the C code is writing to memory it doesn't own.

[mappu]

When i add GODEBUG=cgocheck=2 to my original configuration (GOMAXPROCS=4, no race detector, go 1.8.0), there are no special messages about cgo. I just get the first panic in this thread (unexpected signal during runtime execution) does still happen (in 29/100 runs, plus 6/100 non-terminating).

[ianlancetaylor]

OK, but I'm still guessing memory corruption from your C code rather than a bug in the Go distribution.

I tried to look at your test case but I see that it only runs on Windows and it is large.

[mappu]

The libraries involved do have high-profile authorship... but nothing is above suspicion. I have open tickets with them too.

This has the same error message as #19029 , where #19078 is considered to be the cause. In that thread, it's suggested that 1.8rc3 is unaffected by this issue. But I tried Go 1.8beta1, 1.8beta2, 1.8rc1 and 1.8rc3 , and they all have the same panic behaviour as 1.8 above.

So this panic - whether the underlying fault is in the C code or not - is triggered by some change inbetween 1.7.5 and 1.8beta1. I will attempt to bisect.

[mappu]

I checked out Go src and used git bisect. I knew 1.7.5 worked and 1.8beta1 failed. The test case is quite reliable for me (40 failures in 100 runs) and it took 11 bisections to track down where the panics first appeared.

The first offending commit is ca4089a by @randall77 .

Always, the problem manifests in the same way:

• panic "unexpected signal during runtime execution" when run with GOMAXPROCS=4 no race detector, and
• panic "sweep increased allocation count" when run with GOMAXPROCS=1 regardless of race detector.

EDIT: full bisection log https://gist.github.com/mappu/4df62a83194b6fa158dbc4b6af61f2f9