If proc.Release is called concurrently, a handle will be double-freed.
Change-Id: I0c0c32e312e07bc8615e0bf9e9b691214444d8d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/322510
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We already have a handle to the process, so use that for termination,
rather than doing a new lookup based on the PID.
Change-Id: I2958c1817f12f3dd783412baacbf629049f6956a
Reviewed-on: https://go-review.googlesource.com/c/go/+/322509
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Exposes ErrProcessDone variable in windows and plan9
also returns this error code instead of
errors.New("os: process already finished")
Fixes#42311
Change-Id: Ie807b6526e7b6c27636e6bffe5ff0c904b319be4
GitHub-Last-Rev: 2153e0d702
GitHub-Pull-Request: golang/go#42313
Reviewed-on: https://go-review.googlesource.com/c/go/+/266997
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
CL 208617 introduced syscall.utf16PtrToString and
internal/syscall/windows.UTF16PtrToString functions.
Original version of CL 208617 did not include syscall.utf16PtrToString
and internal/syscall/windows.UTF16PtrToString max parameter. The
parameter was added by Brad at the request of Ian. Ian said:
"In some cases it seems at least possible that the null terminator is
not present. I think it would be safer if we passed a maximum length
here."
The syscall.utf16PtrToString and
internal/syscall/windows.UTF16PtrToString function are designed to work
with only null terminated strings. So max parameter is superfluous.
This change removes max parameter.
Updates #34972
Change-Id: Ifea65dbd86bca8a08353579c6b9636c6f963d165
Reviewed-on: https://go-review.googlesource.com/c/go/+/228858
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change replaces
buf := [HUGE_CONST]*T)(unsafe.Pointer(p))[:]
with
buf := [HUGE_CONST]*T)(unsafe.Pointer(p))[:n:n]
Pointer p points to n of T elements. New unsafe pointer conversion
logic verifies that both first and last elements point into the same
Go variable.
This change replaces [:] with [:n:n] to please pointer checker.
According to @mdempsky, compiler specially recognizes when you
combine a pointer conversion with a full slice operation in a single
expression and makes an exception.
After this, only one failure in net remains when running:
go test -a -short -gcflags=all=-d=checkptr std cmd
Updates #34972
Change-Id: I2c8731650c856264bc788e4e07fa0530f7c250fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/208617
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The wait was there, because we discovered that we could not remove
finished process executable without the wait on Windows XP. But
Windows XP is not supported by Go. Maybe we do not need the wait
with modern Windows versions. Remove the sleep.
Fixes#25965
Change-Id: I02094abee3592ce4fea98eaff9d15137dc54dc81
Reviewed-on: https://go-review.googlesource.com/c/145221
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go uses CommandLineToArgV from shell32.dll to parse command
line parameters. But shell32.dll is slow to load. Implement
Windows command line parsing in Go. This should make starting
Go programs faster.
I can see these speed ups for runtime.BenchmarkRunningGoProgram
on my Windows 7 amd64:
name old time/op new time/op delta
RunningGoProgram-2 11.2ms ± 1% 10.4ms ± 2% -6.63% (p=0.000 n=9+10)
on my Windows XP 386:
name old time/op new time/op delta
RunningGoProgram-2 19.0ms ± 3% 12.1ms ± 1% -36.20% (p=0.000 n=10+10)
on @egonelbre Windows 10 amd64:
name old time/op new time/op delta
RunningGoProgram-8 17.0ms ± 1% 15.3ms ± 2% -9.71% (p=0.000 n=10+10)
This CL is based on CL 22932 by John Starks.
Fixes#15588.
Change-Id: Ib14be0206544d0d4492ca1f0d91fac968be52241
Reviewed-on: https://go-review.googlesource.com/37915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The os package sets a finalizer on *Process. I looked through all the
uses of *Process in the package, looking for each case where a *Process
was passed as an argument and the final reference to the argument was
not a function or method call. I added a call to runtime.KeepAlive after
each such final reference (there were only three).
The code is safe today without the KeepAlive calls because the compiler
keeps arguments alive for the duration of the function. However, that is
not a language requirement, so adding the KeepAlive calls ensures that
this code remains safe even if the compiler changes in the future.
I also removed an existing unnecessry call to runtime.KeepAlive. The
syscall.Syscall function is handled specially by the compiler to keep
its arguments alive.
Change-Id: Ibd2ff20b31ed3de4f6a59dd1633c1b44001d91d9
Reviewed-on: https://go-review.googlesource.com/27637
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd and runtime were handled separately, and I'm intentionally skipped
syscall. This is the rest of the standard library.
CL generated mechanically with github.com/mdempsky/unconvert.
Change-Id: I9e0eff886974dedc37adb93f602064b83e469122
Reviewed-on: https://go-review.googlesource.com/22104
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Process.handle was accessed without synchronization while wait() and
signal() could be called concurrently.
A first solution was to add a Mutex in Process but it was probably too
invasive given Process.handle is only used on Windows.
This version uses atomic operations to read the handle value. There is
still a race between isDone() and the value of the handle, but it only
leads to slightly incorrect error codes. The caller may get a:
errors.New("os: process already finished")
instead of:
syscall.EINVAL
which sounds harmless.
Fixes#9382
Change-Id: Iefcc687a1166d5961c8f27154647b9b15a0f748a
Reviewed-on: https://go-review.googlesource.com/9904
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
While we're here, fix the implementation of Release on both
Unix and Windows: Release is supposed to make Signal an error.
While we're here, make sure we never Signal pid 0.
(Don't try this at home.)
Fixes#7658.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews, iant
https://golang.org/cl/152240043
Jason A. Donenfeld
Alwin Doss
Alex Brainman
Ian Lance Taylor
Matthew Dempsky
Patrick Mezard
Russ Cox