delta/go-git.git/src/runtime/panic.go, branch dev.boringcrypto

runtime: don't discard value from panic while panicking

2022-04-15T01:08:38+00:00

In issue #17671, there are a endless loop if printing
the panic value panics, CL 30358 has fixed that.

As issue #52257 pointed out, above change should not
discard the value from panic while panicking.

With this CL, when we recover from a panic in error.Error()
or stringer.String(), and the recovered value is string,
then we can print it normally.

Fixes #52257

Change-Id: Icfcc4a1a390635de405eea04904b4607ae9e3055
Reviewed-on: https://go-review.googlesource.com/c/go/+/399874
Run-TryBot: Ian Lance Taylor 
TryBot-Result: Gopher Robot 
Reviewed-by: Ian Lance Taylor 
Auto-Submit: Ian Lance Taylor 
Reviewed-by: Dmitri Shuralyov 
Reviewed-by: Dmitri Shuralyov

all: separate doc comment from //go: directives

2022-04-05T17:54:15+00:00

A future change to gofmt will rewrite

	// Doc comment.
	//go:foo

to

	// Doc comment.
	//
	//go:foo

Apply that change preemptively to all comments (not necessarily just doc comments).

For #51082.

Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384260
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Ian Lance Taylor 
TryBot-Result: Gopher Robot

all: gofmt -w -r 'interface{} -> any' src

2021-12-13T18:45:54+00:00

And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.

Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.

A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.

Fixes #49884.

Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09
Reviewed-on: https://go-review.googlesource.com/c/go/+/368254
Trust: Russ Cox 
Run-TryBot: Russ Cox 
Reviewed-by: Robert Griesemer 
TryBot-Result: Gopher Robot

runtime: revert recent Windows crashdump changes

2021-11-09T02:28:30+00:00

Recent changes to runtime enabled crashdumps, which under some
circumstances apparently might result in memory being uploaded to
Microsoft. A change like this should go through the proper proposals
process where we can discuss how to gate it and what all of its
implications are.

This reverts CL 307372 and its cleanup CL 360617.

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

runtime: do not add open defer entry above a started open defer entry

2021-10-29T23:15:00+00:00

Fix two defer bugs related to adding/removing open defer entries.
The bugs relate to the way that we add and remove open defer entries
from the defer chain. At the point of a panic, when we want to start
processing defer entries in order during the panic process, we need to
add entries to the defer chain for stack frames with open defers, since
the normal fast-defer code does not add these entries. We do this by
calling addOneOpenDeferFrame() at the beginning of each time around the
defer loop in gopanic(). Those defer entries get sorted with other open
and non-open-coded defer frames.

However, the tricky part is that we also need to remove defer entries if
they end not being needed because of a recover (which means we are back
to executing the defer code inline at function exits). But we need
to deal with multiple panics and in-process defers on the stack, so we
can't just remove all open-coded defers from the the defer chain during
a recover.

The fix (and new invariant) is that we should not add any open-coded
defers to the defer chain that are higher up the stack than an open-coded
defer that is in progress. We know that open-coded defer will still be
run until completed, and when it is completed, then a more outer frame
will be added (if there is one). This fits with existing code in gopanic
that only removes open-coded defer entries up to any defer in progress.

These bugs were because of the previous inconsistency between adding and
removing open defer entries, which meant that stale defer entries could
be left on the list, in these unusual cases with both recursive
panics plus multiple independent (non-nested) cases of panic & recover.

The test for #48898 was difficult to add to defer_test.go (while keeping
the failure mode), so I added as a go/test/fixedbug test instead.

Fixes #43920
Updates #43941
Fixes #48898

Change-Id: I593b77033e08c33094315abf8089fbc4cab07376
Reviewed-on: https://go-review.googlesource.com/c/go/+/356011
Trust: Dan Scales 
Trust: Cuong Manh Le 
Reviewed-by: Austin Clements

runtime: enable crash dump creation on Windows

2021-10-29T17:44:52+00:00

This change provides ability to create dumps on Windows that can be used by
"dlv core" command. Currently only full dumps can be correctly read by Delve.
Below are the steps to create and use the dumps.

1. Configure Windows OS to collect dumps before running the program.
Instructions on how to do the configuration are here:
https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps.
In order for Delve to read the dump, set the DumpType to full dump, i.e. DumpType=2.

2. Go program only generates dumps when the environment variable GOTRACEBACK
is set to crash. Run command "set GOTRACEBACK=crash" before running the program.

3. Dump files will be generated in %LOCALAPPDATA%\CrashDumps

4. Use Delve command "dlv core" to open the dump, e.g.: "dlv core a.exe a.exe.3840.dmp".

Fixes #20498

Change-Id: Ib9aa82e7aea9da19594dc49348876997b24e9600
Reviewed-on: https://go-review.googlesource.com/c/go/+/307372
Run-TryBot: Alessandro Arzilli 
TryBot-Result: Go Bot 
Reviewed-by: Patrik Nyblom 
Trust: Alex Brainman

runtime: rename _m_ to mp [generated]

2021-10-26T20:12:32+00:00

_g_, _p_, and _m_ are primarily vestiges of the C version of the
runtime, while today we prefer Go-style variable names (generally gp,
pp, and mp).

This change replaces all remaining uses of _m_ with mp. There are very
few remaining and all replacements are trivial.

[git-generate]
cd src/runtime

rf 'mv canpanic._m_ canpanic.mp'
GOOS=solaris \
  rf 'mv semasleep._m_ semasleep.mp'
GOOS=aix GOARCH=ppc64 \
  rf 'mv semasleep._m_ semasleep.mp'

Change-Id: I83690f7b4d4dc57557963100e9a2560ff343f3e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/307813
Trust: Michael Pratt 
Run-TryBot: Michael Pratt 
TryBot-Result: Go Bot 
Reviewed-by: Michael Knyszek

runtime: convert _func.entry to a method

2021-09-27T20:58:49+00:00

A subsequent change will alter the semantics of _func.entry.
To make that change obvious and clear, change _func.entry to a method,
and rename the field to _func.entryPC.

Change-Id: I05d66b54d06c5956d4537b0729ddf4290c3e2635
Reviewed-on: https://go-review.googlesource.com/c/go/+/351460
Trust: Josh Bleecher Snyder 
Run-TryBot: Josh Bleecher Snyder 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] runtime: handle d.link carefully when freeing a defer

2021-08-04T15:51:58+00:00

CL 339396 allowed stack copying on entry to and during freedefer, but
this introduced a subtle bug: if d is heap-allocated, and d.link
points to a stack-allocated defer, stack copying during freedefer can
briefly introduce a stale pointer, which the garbage collector can
discover and panic about. This happens because d has already been
unlinked from the defer chain when freedefer is called, so stack
copying won't update stack pointers in it.

Fix this by making freedefer nosplit again and immediately clearing
d.link.

This should fix the longtest builders, which currently fail on
GOMAXPROCS=2 runtime -cpu=1,2,4 -quick in the TestDeferHeapAndStack
test.

This seems like the simplest fix, but it just deals with the subtlety
rather than eliminating it. Really, every call site of freedefer (of
which there are surprisingly many) has hidden subtlety between
unlinking the defer and calling freedefer. We could consolidate the
subtlety into each call site by requiring that they unlink the defer
and set d.link to nil before calling freedefer. freedefer could check
this condition like it checks that various other fields have already
been zeroed. A more radical option is to replace freedefer with
"popDefer", which would both pop the defer off the link and take care
of freeing it. There would still be a brief moment of subtlety, but it
would be in one place, in popDefer. Annoyingly, *almost* every call to
freedefer just pops the defer from the head of the G's list, but
there's one place when handling open-coded defers where we have to
remove a defer from the middle of the list. I'm inclined to first fix
that subtlety by only expanding open-coded defer records when they're
at the head of the defer list, and then revisit the popDefer idea.

Change-Id: I3130d2542c01a421a5d60e8c31f5379263219627
Reviewed-on: https://go-review.googlesource.com/c/go/+/339730
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui

[dev.typeparams] runtime: simplify freedefer

2021-08-03T21:23:25+00:00

Currently, freedefer manually zeros all the fields in the _defer
because simply assigning _defer{} used to cause a nosplit stack
overflow. freedefer is no longer nosplit, so go back to the simpler,
more robust code.

Change-Id: I881f557bab3b1ee7ab29b68e7fb56d0fe6d35d8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/339669
Trust: Austin Clements 
Run-TryBot: Austin Clements 
TryBot-Result: Go Bot 
Reviewed-by: Cherry Mui