Skip to content

G
golang
Switch branch/tag
  1. 18 Dec, 2015 4 commits
    • Austin Clements's avatar
      runtime: require the stack barrier lock to traceback cgo and libcalls · f90b48e0
      Austin Clements authored 
      Currently, if sigprof determines that the G is in user code (not cgo
or libcall code), it will only traceback the G stack if it can acquire
the stack barrier lock. However, it has no such restriction if the G
is in cgo or libcall code. Because cgo calls count as syscalls, stack
scanning and stack barrier installation can occur during a cgo call,
which means sigprof could attempt to traceback a G in a cgo call while
scanstack is installing stack barriers in that G's stack. As a result,
the following sequence of events can cause the sigprof traceback to
panic with "missed stack barrier":

1. M1: G1 performs a Cgo call (which, on Windows, is any system call,
   which could explain why this is easier to reproduce on Windows).

2. M1: The Cgo call puts G1 into _Gsyscall state.

3. M2: GC starts a scan of G1's stack. It puts G1 in to _Gscansyscall
   and acquires the stack barrier lock.

4. M3: A profiling signal comes in. On Windows this is a global
   (though I don't think this matters), so the runtime stops M1 and
   calls sigprof for G1.

5. M3: sigprof fails to acquire the stack barrier lock (because the
   GC's stack scan holds it).

6. M3: sigprof observes that G1 is in a Cgo call, so it calls
   gentraceback on G1 with its Cgo transition point.

7. M3: gentraceback on G1 grabs the currently empty g.stkbar slice.

8. M2: GC finishes scanning G1's stack and installing stack barriers.

9. M3: gentraceback encounters one of the just-installed stack
   barriers and panics.

This commit fixes this by only allowing cgo tracebacks if sigprof can
acquire the stack barrier lock, just like in the regular user
traceback case.

For good measure, we put the same constraint on libcall tracebacks.
This case is probably already safe because, unlike cgo calls, libcalls
leave the G in _Grunning and prevent reaching a safe point, so
scanstack cannot run during a libcall. However, this also means that
sigprof will always acquire the stack barrier lock without contention,
so there's no cost to adding this constraint to libcall tracebacks.

Fixes #12528. For 1.5.3 (will require some backporting).

Change-Id: Ia5a4b8e3d66b23b02ffcd54c6315c81055c0cec2
Reviewed-on: https://go-review.googlesource.com/18023
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      f90b48e0
    • Austin Clements's avatar
      runtime: prevent race between setNextBarrierPC and sigprof · a4a57bb4
      Austin Clements authored 
      Currently, setNextBarrierPC manipulates the stack barriers without
acquiring the stack barrier lock. This is mostly okay because
setNextBarrierPC also runs synchronously on the G and prevents safe
points, but this doesn't prevent a sigprof from occurring during a
setNextBarrierPC and performing a traceback.

Given that setNextBarrierPC simply sets one entry in the stack barrier
array, this is almost certainly safe in reality. However, given that
this depends on a subtle argument, which may not hold in the future,
and that setNextBarrierPC almost never happens, making it nowhere near
performance-critical, we can simply acquire the stack barrier lock and
be sure that the synchronization will work.

Updates #12528. For 1.5.3.

Change-Id: Ife696e10d969f190157eb1cbe762a2de2ebce079
Reviewed-on: https://go-review.googlesource.com/18022
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      a4a57bb4
    • Emmanuel Odeke's avatar
      doc: fix typo in go1.6.html · 90a68935
      Emmanuel Odeke authored 
      Change-Id: I7405cf6f65bccbb07a27f2dc2e3802cab591e296
Reviewed-on: https://go-review.googlesource.com/18030Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      90a68935
    • Ian Lance Taylor's avatar
      cmd/vet: add some checks for invalid pointer passing using cgo · ebf64bcc
      Ian Lance Taylor authored 
      Update #12416.

Change-Id: I21d97cbe211ccc8048e5a78ea4d89664f4d195ba
Reviewed-on: https://go-review.googlesource.com/17041Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      ebf64bcc
  3. 17 Dec, 2015 36 commits