delta/go-git.git/src/runtime/testdata, branch dev.debug

runtime: get more info for TestCgoSignalDeadlock failures

2017-06-27T00:34:53+00:00

Updates #18598

Change-Id: I13c60124714cf9d1537efa0a7dd1e6a0fed9ae5b
Reviewed-on: https://go-review.googlesource.com/46723
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

runtime: don't run TestCgoNumGoroutine on Windows or Plan 9

2017-06-14T17:28:02+00:00

The test requires pthreads.

Fixes #20666.

Change-Id: Icb2400250a80cdad6680cd1ef6c18ef7343d5e29
Reviewed-on: https://go-review.googlesource.com/45701
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Brad Fitzpatrick 
TryBot-Result: Gobot Gobot

runtime, syscall: reset signal handlers to default in child

2017-06-14T14:00:56+00:00

Block all signals during a fork. In the parent process, after the
fork, restore the signal mask. In the child process, reset all
currently handled signals to the default handler, and then restore the
signal mask.

The effect of this is that the child will be operating using the same
signal regime as the program it is about to exec, as exec resets all
non-ignored signals to the default, and preserves the signal mask.

We do this so that in the case of a signal sent to the process group,
the child process will not try to run a signal handler while in the
precarious state after a fork.

Fixes #18600.

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

runtime: mark extra M's G as dead when not in use

2017-06-07T02:13:51+00:00

Currently the extra Ms created for cgo callbacks have a corresponding
G that's kept in syscall state with only a call to goexit on its
stack. This leads to confusing output from runtime.NumGoroutines and
in tracebacks:

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	.../src/runtime/asm_amd64.s:2197 +0x1

Fix this by putting this goroutine into state _Gdead when it's not in
use instead of _Gsyscall. To keep the goroutine counts correct, we
also add one to sched.ngsys while the goroutine is in _Gdead. The
effect of this is as if the goroutine simply doesn't exist when it's
not in use.

Fixes #16631.
Fixes #16714.

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

runtime: delay exiting while panic is running deferred functions

2017-06-05T22:42:48+00:00

Try to avoid a race between the main goroutine exiting and a panic
occurring. Don't try too hard, to avoid hanging.

Updates #3934
Fixes #20018

Change-Id: I57a02b6d795d2a61f1cadd137ce097145280ece7
Reviewed-on: https://go-review.googlesource.com/41052
Reviewed-by: Austin Clements

runtime: use cpuset_getaffinity for runtime.NumCPU() on FreeBSD

2017-03-10T22:06:24+00:00

In FreeBSD when run Go proc under a given sub-list of
processors(e.g. 'cpuset -l 0 ./a.out' in multi-core system),
runtime.NumCPU() still return all physical CPUs from sysctl
hw.ncpu instead of account from sub-list.

Fix by use syscall cpuset_getaffinity to account the number of sub-list.

Fixes #15206

Change-Id: If87c4b620e870486efa100685db5debbf1210a5b
Reviewed-on: https://go-review.googlesource.com/29341
Reviewed-by: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor

runtime: add explicit (void) in C to avoid GCC 7 problem

2017-01-30T19:27:49+00:00

This avoids errors like
    ./traceback.go:80:2: call of non-function C.f1

I filed https://gcc.gnu.org/PR79289 for the GCC problem. I think this
is a bug in GCC, and it may be fixed before the final GCC 7 release.
This CL is correct either way.

Fixes #18855.

Change-Id: I0785a7b7c5b1d0ca87b454b5eca9079f390fcbd4
Reviewed-on: https://go-review.googlesource.com/35919
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: David Crawshaw

all: make copyright headers consistent with one space after period

2016-11-04T20:46:25+00:00

Continuation of CL 20111.

Change-Id: Ie2f62237e6ec316989c021de9b267cc9d6ee6676
Reviewed-on: https://go-review.googlesource.com/32830
Reviewed-by: Brad Fitzpatrick

runtime/testdata/testprog: increase GCFairness2 timeout to 1s

2016-11-03T15:48:57+00:00

OpenBSD's scheduler causes preemption to take 20+ms, so 30ms is not
enough time for 3 goroutines to run. This change continues to sleep for
30ms, but if it finds that the 3 goroutines have not run, it sleeps for
an additional 1s before declaring failure.

Updates #17712

Change-Id: I3e886e40d05192b7cb71b4f242af195836ef62a8
Reviewed-on: https://go-review.googlesource.com/32634
Reviewed-by: Rick Hudson 
Run-TryBot: Quentin Smith 
TryBot-Result: Gobot Gobot

runtime: record current PC for SIGPROF on non-Go thread

2016-10-11T12:56:15+00:00

If we get a SIGPROF on a non-Go thread, and the program has not called
runtime.SetCgoTraceback so we have no way to collect a stack trace, then
record a profile that is just the PC where the signal occurred. That
will at least point the user to the right area.

Retrieving the PC from the sigctxt in a signal handler on a non-G thread
required marking a number of trivial sigctxt methods as nosplit, and,
for extra safety, nowritebarrierrec.

The test shows that the existing test CgoPprofThread test does not test
the stack trace, just the profile signal. Leaving that for later.

Change-Id: I8f8f3ff09ac099fc9d9df94b5a9d210ffc20c4ab
Reviewed-on: https://go-review.googlesource.com/30252
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gobot Gobot 
Reviewed-by: Dmitry Vyukov