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

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

Closed
mappu opened this issue Mar 9, 2017 · 17 comments

Comments

Projects
None yet
7 participants
@mappu
Copy link

commented Mar 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2017

@mappu

This comment has been minimized.

Copy link
Author

commented Mar 9, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 9, 2017

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 ianlancetaylor changed the title send on channel panics with "unexpected signal during runtime execution" runtime: send on channel panics with "unexpected signal during runtime execution" Mar 9, 2017

@ianlancetaylor ianlancetaylor added this to the Go1.9 milestone Mar 9, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 13, 2017

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

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 14, 2017

@mappu, does your crashing application use finalizers?

@mappu

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

Apparently yes it does.

github.com/Microsoft/go-winio/backup.go:        runtime.SetFinalizer(r, func(r *BackupFileReader) { r.Close() })
github.com/Microsoft/go-winio/backup.go:        runtime.SetFinalizer(w, func(w *BackupFileWriter) { w.Close() })
github.com/Microsoft/go-winio/file.go:  runtime.SetFinalizer(f, (*win32File).closeHandle)
github.com/Microsoft/go-winio/file.go:  runtime.SetFinalizer(f, nil)
@mappu

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

I think i see where you're going with this. Go1.8 may require additional calls to runtime.KeepAlive ? It looks like these are missing. I'll read more on the subject but it looks like the issue is in https://github.com/Microsoft/go-winio/ .

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 14, 2017

@mappu, yup. That's my guess.

@mappu

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

I totally removed all calls to runtime.SetFinalizer, but this didn't change anything. The same panic occurs in runtime.

@mappu

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

Panic is consistent with different C toolchains.

Compiler version Host Target
gcc (x86_64-win32-seh-rev4, Built by MinGW-W64 project) 4.9.2 win64 win64
x86_64-w64-mingw32-gcc (GCC) 5.4.0 cygwin32 win64
gcc (x86_64-win32-seh-rev1, Built by MinGW-W64 project) 6.3.0 win64 win64

@mikioh mikioh closed this Mar 14, 2017

@mikioh mikioh reopened this Mar 14, 2017

@aclements

This comment has been minimized.

Copy link
Member

commented Jun 12, 2017

@mappu, looking over your code, I don't understand what's supposed to be happening. In particular, here:

//sys getQueuedCompletionStatus(port syscall.Handle, bytes *uint32, key *uintptr, o **ioOperation, timeout uint32) (err error) = GetQueuedCompletionStatus

// ioOperation represents an outstanding asynchronous Win32 IO
type ioOperation struct {
	o  syscall.Overlapped
	ch chan ioResult
}

// ioCompletionProcessor processes completed async IOs forever
func ioCompletionProcessor(h syscall.Handle) {
	// Set the timer resolution to 1. This fixes a performance regression in golang 1.6.
	timeBeginPeriod(1)
	for {
		var bytes uint32
		var key uintptr
		var op *ioOperation
		err := getQueuedCompletionStatus(h, &bytes, &key, &op, syscall.INFINITE)
		if op == nil {
			panic(err)
		}
		op.ch <- ioResult{bytes, err}
	}
}

I haven't read up on IO completion ports, but it looks like the ioOperation is created by the syscall getQueuedCompletionStatus itself. Given that GetQueuedCompletionStatus takes an LPOVERLAPPED, I would expect the resulting *ioOperation to only have its o syscall.Overlapped field filled in and for the ch field to be garbage, which is consistent with what you're seeing. Where is op.ch supposed to come from?

@mappu

This comment has been minimized.

Copy link
Author

commented Jun 13, 2017

Hi @aclements, that's a great discovery. It looks like a bug to me too. It should be reported to Microsoft in their upstream repository https://github.com/Microsoft/go-winio/issues .

Upstream do seem to think the earlier suggestion about go1.8 finalizer changes was correct, and they have closed my corresponding issue in their own repo. But, i haven't retried my original test case against their latest code. I'll do that today and follow up this ticket.

@mappu

This comment has been minimized.

Copy link
Author

commented Jun 13, 2017

I re-ran the test case with the updated vendor code, and can confirm the issue is resolved. && In the end it wasn't Go's fault.

Thanks everyone for your assistance in troubleshooting this issue, i will close the ticket.

@aclements despite it being a very weird construct, it does seem to work now that the finalizer behaviours were changed in upstream, so it's (probably??) not a bug...

@mappu mappu closed this Jun 13, 2017

whilei added a commit to whilei/go-ethereum that referenced this issue Nov 6, 2017

update rpc/vendor/github.com/microsoft/go-winio at 78439966b38d69bf38…
…227fbf57ac8a6fee70f69a

problem: fatal error: unexpected signal during runtime execution
when running 'monitor' command on win 7 sp1

note: awslabs/aws-sam-cli#112
note: microsoft/go-winio#41
note: golang/go#19468 (comment) [not go issue]

solution:
update microsoft/go-winio vendor dependency

Rel ethereumproject#392

whilei added a commit to ethereumproject/go-ethereum that referenced this issue Nov 8, 2017

update rpc/vendor/github.com/microsoft/go-winio at 78439966b38d69bf38…
…227fbf57ac8a6fee70f69a

problem: fatal error: unexpected signal during runtime execution
when running 'monitor' command on win 7 sp1

note: awslabs/aws-sam-cli#112
note: microsoft/go-winio#41
note: golang/go#19468 (comment) [not go issue]

solution:
update microsoft/go-winio vendor dependency

Rel #392

----

manually remove vendored winio tests

remove dirs from vendored go-winio

Revert "remove dirs from vendored go-winio"

This reverts commit 67c9236.

remove subdir go _test files from manually vendored winio package

whilei added a commit to ethereumproject/go-ethereum that referenced this issue Nov 8, 2017

update rpc/vendor/github.com/microsoft/go-winio at 78439966b38d69bf38…
…227fbf57ac8a6fee70f69a

problem: fatal error: unexpected signal during runtime execution
when running 'monitor' command on win 7 sp1

note: awslabs/aws-sam-cli#112
note: microsoft/go-winio#41
note: golang/go#19468 (comment) [not go issue]

solution:
update microsoft/go-winio vendor dependency

Rel #392

----
manually remove vendored winio tests
----
remove dirs from vendored go-winio
----
Revert "remove dirs from vendored go-winio"

This reverts commit 67c9236.
----
remove subdir go _test files from manually vendored winio package
----
rm -rf archive/tar/testdata

@golang golang locked and limited conversation to collaborators Jun 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.