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

runtime: avoid possible preemption when returning from Go to C

2021-07-29T15:30:38+00:00

When returning from Go to C, it was possible for the goroutine to be
preempted after calling unlockOSThread. This could happen when there
a context function installed by SetCgoTraceback set a non-zero context,
leading to a defer call in cgocallbackg1. The defer function wrapper,
introduced in 1.17 as part of the regabi support, was not nosplit,
and hence was a potential preemption point. If it did get preempted,
the G would move to a new M. It would then attempt to return to C
code on a different stack, typically leading to a SIGSEGV.

Fix this in a simple way by postponing the unlockOSThread until after
the other defer. Also check for the failure condition and fail early,
rather than waiting for a SIGSEGV.

Without the fix to cgocall.go, the test case fails about 50% of the
time on my laptop.

Fixes #47441

Change-Id: Ib8ca13215bd36cddc2a49e86698824a29c6a68ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/338197
Trust: Ian Lance Taylor 
Reviewed-by: Keith Randall 
Reviewed-by: Cherry Mui

runtime: don't crash on nil pointers in checkptrAlignment

2021-07-28T03:27:13+00:00

Ironically, checkptrAlignment had a latent case of bad pointer
arithmetic: if ptr is nil, then `add(ptr, size-1)` might produce an
illegal pointer value.

The fix is to simply check for nil at the top of checkptrAlignment,
and short-circuit if so.

This CL also adds a more explicit bounds check in checkptrStraddles,
rather than relying on `add(ptr, size-1)` to wrap around. I don't
think this is necessary today, but it seems prudent to be careful.

Fixes #47430.

Change-Id: I5c50b2f7f41415dbebbd803e1b8e7766ca95e1fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/338029
Trust: Matthew Dempsky 
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Reviewed-by: Keith Randall

cmd/compile,runtime: change unsafe.Slice((*T)(nil), 0) to return []T(nil)

2021-06-28T23:31:13+00:00

This CL removes the unconditional OCHECKNIL check added in
walkUnsafeSlice by instead passing it as a pointer to
runtime.unsafeslice, and hiding the check behind a `len == 0` check.

While here, this CL also implements checkptr functionality for
unsafe.Slice and disallows use of unsafe.Slice with //go:notinheap
types.

Updates #46742.

Change-Id: I743a445ac124304a4d7322a7fe089c4a21b9a655
Reviewed-on: https://go-review.googlesource.com/c/go/+/331070
Run-TryBot: Matthew Dempsky 
TryBot-Result: Go Bot 
Trust: Matthew Dempsky 
Reviewed-by: Keith Randall

runtime: testprogcgo: don't call exported Go functions directly from Go

2021-06-12T16:07:12+00:00

Instead route through a C function, to avoid declaration conflicts
between the declaration needed in the cgo comment and the declaration
generated by cgo in _cgo_export.h.

This is not something user code will ever do, so no need to make it
work in cgo.

Fixes #46502

Change-Id: I1bfffdc76ef8ea63e3829871298d0774157957a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/327309
Trust: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui 
Reviewed-by: Jason A. Donenfeld

runtime: wait for Go runtime to initialize in Windows signal test

2021-05-21T13:21:00+00:00

The test harness waits for "ready" as a sign that the Go runtime has
installed its signal handler and is ready to be tested. But actually,
while LoadLibrary starts the loading of the Go runtime, it does so
asynchronously, so the "ready" sign is potentially premature and
certainly racy. However, all exported cgo entry points make a call to
_cgo_wait_runtime_init_done which waits for that asynchronous
initialization to complete. Therefore, this commit fixes the test to
call into the exported "Dummy" cgo function before emitting the "ready"
sign, so that we're sure the Go runtime is actually loaded.

Updates #45638.

Change-Id: I9b12b172d45bdcc09d54dd301de3a3e499544834
Reviewed-on: https://go-review.googlesource.com/c/go/+/321769
Trust: Jason A. Donenfeld 
Run-TryBot: Jason A. Donenfeld 
TryBot-Result: Go Bot 
Reviewed-by: Michael Knyszek

runtime: add missing import "C" in TestLibraryCtrlHandler

2021-04-27T08:36:54+00:00

CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.

While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.

TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.

Updates #45638

Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman 
Run-TryBot: Alex Brainman 
TryBot-Result: Go Bot 
Reviewed-by: Michael Knyszek

runtime/testdata: fix testprogcgo for windows/arm64

2021-04-23T21:43:10+00:00

Our toolchain does not like -mnop-fun-dllimport.

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

runtime: don't run TestCrashDumpsAllThreads in parallel

2021-04-22T00:34:25+00:00

It sometimes seems to time out on slow systems, perhaps due to
being run at the same time as a lot of other work.

Also move the code to testdata/testprog, so that we don't have to
build it separately.

I hope that this
Fixes #35356

Change-Id: I875b858fa23836513ae14d3116461e22fffd5352
Reviewed-on: https://go-review.googlesource.com/c/go/+/312510
Trust: Ian Lance Taylor 
Run-TryBot: Ian Lance Taylor 
Reviewed-by: Cherry Zhang 
TryBot-Result: Go Bot

all: run gofmt

2021-03-15T21:49:19+00:00

Fixes #44980

Change-Id: Icef35319d1582d8367c8911e15d11b0224957327
GitHub-Last-Rev: 2113e97e837c1ef5de9ba6a7bd62db92e644c500
GitHub-Pull-Request: golang/go#45005
Reviewed-on: https://go-review.googlesource.com/c/go/+/301632
Reviewed-by: Ian Lance Taylor 
Trust: Josh Bleecher Snyder

runtime: make sure to remove open-coded defer entries in all cases after a recover

2021-01-27T20:44:24+00:00

We add entries to the defer list at panic/goexit time on-the-fly for
frames with open-coded defers. We do this so that we can correctly
process open-coded defers and non-open-coded defers in the correct order
during panics/goexits. But we need to remove entries for open-coded
defers from the defer list when there is a recover, since those entries
may never get removed otherwise and will get stale, since their
corresponding defers may now be processed normally (inline).

This bug here is that we were only removing higher-up stale entries
during a recover if all defers in the current frame were done. But we
could have more defers in the current frame (as the new test case
shows). In this case, we need to leave the current defer entry around
for use by deferreturn, but still remove any stale entries further along
the chain.

For bug 43921, simple change that we should abort the removal loop for
any defer entry that is started (i.e. in process by a still
not-recovered outer panic), even if it is not an open-coded defer.

This change does not fix bug 43920, which looks to be a more complex fix.

Fixes #43882
Fixes #43921

Change-Id: Ie05b2fa26973aa26b25c8899a2abc916090ee4f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/286712
Run-TryBot: Dan Scales 
TryBot-Result: Go Bot 
Reviewed-by: Matthew Dempsky 
Reviewed-by: Keith Randall 
Trust: Dan Scales