Skip to content

G
golang
Switch branch/tag
  1. 11 Jun, 2015 2 commits
    • David du Colombier's avatar
      os: fix error returned by dirstat on Plan 9 · bd8e3d02
      David du Colombier authored 
      When the Stat or Fstat system calls return -1,
dirstat incorrectly returns ErrShortStat.

However, the error returned by Stat or Fstat
could be different. For example, when the
file doesn't exist, they return "does not exist".

Dirstat should return the error returned by
the system call.

Fixes #10911.
Fixes #11132.

Change-Id: Icf242d203d256f12366b1e277f99b1458385104a
Reviewed-on: https://go-review.googlesource.com/10900
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      bd8e3d02
    • Patrick Mezard's avatar
      os: fix a race between Process.signal() and wait() on Windows · d574b59f
      Patrick Mezard authored 
      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/9904Reviewed-by: 's avatarAlex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      d574b59f
  3. 10 Jun, 2015 6 commits
  5. 09 Jun, 2015 13 commits
  7. 08 Jun, 2015 5 commits
  9. 07 Jun, 2015 4 commits
    • Austin Clements's avatar
      runtime: unwind stack barriers when writing above the current frame · 306f8f11
      Austin Clements authored 
      Stack barriers assume that writes through pointers to frames above the
current frame will get write barriers, and hence these frames do not
need to be re-scanned to pick up these changes. For normal writes,
this is true. However, there are places in the runtime that use
typedmemmove to potentially write through pointers to higher frames
(such as mapassign1). Currently, typedmemmove does not execute write
barriers if the destination is on the stack. If there's a stack
barrier between the current frame and the frame being modified with
typedmemmove, and the stack barrier is not otherwise hit, it's
possible that the garbage collector will never see the updated pointer
and incorrectly reclaim the object.

Fix this by making heapBitsBulkBarrier (which lies behind typedmemmove
and its variants) detect when the destination is in the stack and
unwind stack barriers up to the point, forcing mark termination to
later rescan the effected frame and collect these pointers.

Fixes #11084. Might be related to #10240, #10541, #10941, #11023,
 #11027 and possibly others.

Change-Id: I323d6cd0f1d29fa01f8fc946f4b90e04ef210efd
Reviewed-on: https://go-review.googlesource.com/10791Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      306f8f11
    • Austin Clements's avatar
      runtime: enable write barriers during concurrent scan · 1303957d
      Austin Clements authored 
      Currently, write barriers are only enabled after completion of the
concurrent scan phase, as we enter the concurrent mark phase. However,
stack barriers are installed during the scan phase and assume that
write barriers will track changes to frames above the stack
barriers. Since write barriers aren't enabled until after stack
barriers are installed, we may miss modifications to the stack that
happen after installing the stack barriers and before enabling write
barriers.

Fix this by enabling write barriers during the scan phase.

This commit intentionally makes the minimal change to do this (there's
only one line of code change; the rest are comment changes). At the
very least, we should consider eliminating the ragged barrier that's
intended to synchronize the enabling of write barriers, but now just
wastes time. I've included a large comment about extensions and
alternative designs.

Change-Id: Ib20fede794e4fcb91ddf36f99bd97344d7f96421
Reviewed-on: https://go-review.googlesource.com/10795Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      1303957d
    • Austin Clements's avatar
      runtime: fix checkmarks to rescan stacks · 6f6403ed
      Austin Clements authored 
      Currently checkmarks mode fails to rescan stacks because it sees the
leftover state bits indicating that the stacks haven't changed since
the last scan. As a result, it won't detect lost marks caused by
failing to scan stacks correctly during regular garbage collection.

Fix this by marking all stacks dirty before performing the checkmark
phase.

Change-Id: I1f06882bb8b20257120a4b8e7f95bb3ffc263895
Reviewed-on: https://go-review.googlesource.com/10794Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      6f6403ed
    • Dominik Honnef's avatar
      doc/go1.5.txt: correct CL for LookupEnv addition · 0599913a
      Dominik Honnef authored 
      Change-Id: Ib43b21daef5d8291e03c0f0fbf56999e37e21e21
Reviewed-on: https://go-review.googlesource.com/10820Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      0599913a
  11. 06 Jun, 2015 5 commits
  13. 05 Jun, 2015 5 commits