delta/go-git.git/src/runtime/debug_test.go, branch dev.go2go

all: go fmt std cmd (but revert vendor)

2021-02-20T03:54:50+00:00

Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).

Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild

Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Go Bot 
Reviewed-by: Jason A. Donenfeld 
Reviewed-by: Ian Lance Taylor

all: update to use os.ReadFile, os.WriteFile, os.CreateTemp, os.MkdirTemp

2020-12-09T19:12:23+00:00

As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)

Update the Go tree to use the preferred names.

As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.

ReadDir changes are in a separate CL, because they are not a
simple search and replace.

For #42026.

Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox 
Run-TryBot: Russ Cox 
TryBot-Result: Go Bot 
Reviewed-by: Ian Lance Taylor

runtime: if InjectDebugCall sees "not at safe point", keep trying

2019-11-08T18:39:41+00:00

Fixes #35376

Change-Id: Ib95ad336425e73cc4d412dafed0ba5e0a8130bd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/205718
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: Bryan C. Mills

runtime: fix hangs in TestDebugCall*

2018-12-17T03:00:28+00:00

This fixes a few different issues that led to hangs and general
flakiness in the TestDebugCall* tests.

1. This fixes missing wake-ups in two error paths of the SIGTRAP
   signal handler. If the goroutine was in an unknown state, or if
   there was an unknown debug call status, we currently don't wake the
   injection coordinator. These are terminal states, so this resulted
   in a hang.

2. This adds a retry if the target goroutine is in a transient state
   that prevents us from injecting a call. The most common failure
   mode here is that the target goroutine is in _Grunnable, but this
   was previously masked because it deadlocked the test.

3. Related to 2, this switches the "ready" signal from the target
   goroutine from a blocking channel send to a non-blocking channel
   send. This makes it much less likely that we'll catch this
   goroutine while it's in the runtime performing that send.

4. This increases GOMAXPROCS from 2 to 8 during these tests. With the
   current setting of 2, we can have at most the non-preemptible
   goroutine we're injecting a call in to and the goroutine that's
   trying to make it exit. If anything else comes along, it can
   deadlock. One particular case I observed was in TestDebugCallGC,
   where runtime.GC() returns before the forEachP that prepares
   sweeping on all goroutines has finished. When this happens, the
   forEachP blocks on the non-preemptible loop, which means we now
   have at least three goroutines that need to run.

Fixes #25519.

Updates #29124.

Change-Id: I7bc41dc0b865b7d0bb379cb654f9a1218bc37428
Reviewed-on: https://go-review.googlesource.com/c/154112
Run-TryBot: Austin Clements 
Reviewed-by: Michael Knyszek

runtime: skip debug call injection tests under a debugger

2018-10-03T20:32:28+00:00

The debug call injection tests will freeze when run under a debugger
because they depend on catching SIGTRAP, which is usually swallowed by
a debugger.

Change-Id: If6b86ca279b0489182990dd513444ca3062973f1
Reviewed-on: https://go-review.googlesource.com/c/139437
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Keith Randall

runtime: check tgkill error in Debug tests

2018-07-13T17:17:54+00:00

Updates #25519

Change-Id: Ibcdf948fd38d8d02d467b62213566ec0d7ce0d6a
Reviewed-on: https://go-review.googlesource.com/123180
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: Austin Clements

runtime: fix preemption deadlocks in TestDebugCall*

2018-05-24T15:39:56+00:00

TestDebugCall* uses atomic spin loops and hence can deadlock if the
garbage collector is enabled (because of #10958; ironically,
implementing debugger call injection is closely related to fixing this
exact issue, but we're not there yet).

Fix this by disabling the garbage collector during these tests.

Updates #25519 (might fix it, though I suspect not)

Change-Id: If1e454b9cdea8e4b1cd82509b762c75b6acd8476
Reviewed-on: https://go-review.googlesource.com/114086
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Keith Randall

runtime: support for debugger function calls

2018-05-22T15:55:05+00:00

This adds a mechanism for debuggers to safely inject calls to Go
functions on amd64. Debuggers must participate in a protocol with the
runtime, and need to know how to lay out a call frame, but the runtime
support takes care of the details of handling live pointers in
registers, stack growth, and detecting the trickier conditions when it
is unsafe to inject a user function call.

Fixes #21678.
Updates derekparker/delve#119.

Change-Id: I56d8ca67700f1f77e19d89e7fc92ab337b228834
Reviewed-on: https://go-review.googlesource.com/109699
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Keith Randall