delta/go-git.git/src/runtime/traceback.go, branch dev.inline

runtime: do not print runtime panic frame at top of user stack

2016-11-22T18:33:30+00:00

The expected default behavior (no explicit GOTRACEBACK setting)
is for the stack trace to start in user code, eliding unnecessary runtime
frames that led up to the actual trace printing code. The idea was that
the first line number printed was the one that crashed.

For #5832 we added code to show 'panic' frames so that if code panics
and then starts running defers and then we trace from there, the panic
frame can help explain why the code seems to have made a call not
present in the code. But that's only needed for panics between two different
call frames, not the panic at the very top of the stack trace.
Fix the fix to again elide the runtime code at the very top of the stack trace.

Simple panic:

	package main

	func main() {
		var x []int
		println(x[1])
	}

Before this CL:

	panic: runtime error: index out of range

	goroutine 1 [running]:
	panic(0x1056980, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
	main.main()
		/tmp/x.go:5 +0x5

After this CL:

	panic: runtime error: index out of range

	goroutine 1 [running]:
	main.main()
		/tmp/x.go:5 +0x5

Panic inside defer triggered by panic:

	package main

	func main() {
		var x []int
		defer func() {
			println(x[1])
		}()
		println(x[2])
	}

Before this CL:

	panic: runtime error: index out of range
		panic: runtime error: index out of range

	goroutine 1 [running]:
	panic(0x1056aa0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
	main.main.func1(0x0, 0x0, 0x0)
		/tmp/y.go:6 +0x62
	panic(0x1056aa0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
	main.main()
		/tmp/y.go:8 +0x59

The middle panic is important: it explains why main.main ended up calling main.main.func1 on a line that looks like a call to println. The top panic is noise.

After this CL:

	panic: runtime error: index out of range
		panic: runtime error: index out of range

	goroutine 1 [running]:
	main.main.func1(0x0, 0x0, 0x0)
		/tmp/y.go:6 +0x62
	panic(0x1056ac0, 0x1091bf0)
		/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
	main.main()
		/tmp/y.go:8 +0x59

Fixes #17901.

Change-Id: Id6d7c76373f7a658a537a39ca32b7dc23e1e76aa
Reviewed-on: https://go-review.googlesource.com/33165
Run-TryBot: Russ Cox 
TryBot-Result: Gobot Gobot 
Reviewed-by: Ian Lance Taylor 
Reviewed-by: Brad Fitzpatrick

runtime: fix getArgInfo for deferred reflection calls

2016-10-17T18:57:01+00:00

getArgInfo for reflect.makeFuncStub and reflect.methodValueCall is
necessarily special. These have dynamically determined argument maps
that are stored in their context (that is, their *funcval). These
functions are written to store this context at 0(SP) when called, and
getArgInfo retrieves it from there.

This technique works if getArgInfo is passed an active call frame for
one of these functions. However, getArgInfo is also used in
tracebackdefers, where the "call" is not a true call with an active
stack frame, but a deferred call. In this situation, getArgInfo
currently crashes because tracebackdefers passes a frame with sp set
to 0. However, the entire approach used by getArgInfo is flawed in
this situation because the wrapper has not actually executed, and
hence hasn't saved this metadata to any stack frame.

In the defer case, we know the *funcval from the _defer itself, so we
can fix this by teaching getArgInfo to use the *funcval context
directly when its available, and otherwise get it from the active call
frame.

While we're here, this commit simplifies getArgInfo a bit by making it
play more nicely with the type system. Rather than decoding the
*reflect.methodValue that is the wrapper's context as a *[2]uintptr,
just write out a copy of the reflect.methodValue type in the runtime.

Fixes #16331. Fixes #17471.

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

runtime: add msan calls before calling traceback functions

2016-08-23T16:31:16+00:00

Tell msan that the arguments to the traceback functions are initialized,
in case the traceback functions are compiled with -fsanitize=memory.

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

runtime: only permit SetCgoTraceback to be called once

2016-06-02T19:24:55+00:00

Accept a duplicate call, but nothing else.

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

runtime: fix typo in comment

2016-06-02T06:02:01+00:00

Change-Id: I82e35770b45ccd1433dfae0af423073c312c0859
Reviewed-on: https://go-review.googlesource.com/23680
Reviewed-by: Andrew Gerrand

runtime: pass signal context to cgo traceback function

2016-05-31T21:17:40+00:00

When doing a backtrace from a signal that occurs in C code compiled
without using -fasynchronous-unwind-tables, we have to rely on frame
pointers. In order to do that, the traceback function needs the signal
context to reliably pick up the frame pointer.

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

runtime: update SP when jumping stacks in traceback

2016-05-24T21:07:24+00:00

When gentraceback starts on a system stack in sigprof, it is
configured to jump to the user stack when it reaches the end of the
system stack. Currently this updates the current frame's FP, but not
its SP. This is okay on non-LR machines (x86) because frame.sp is only
used to find defers, which the bottom-most frame of the user stack
will never have.

However, on LR machines, we use frame.sp to find the saved LR. We then
use to resolve the function of the next frame, which is used to
resolved the size of the next frame. Since we're not updating frame.sp
on a stack jump, we read the saved LR from the system stack instead of
the user stack and wind up resolving the wrong function and hence the
wrong frame size for the next frame.

This has had remarkably few ill effects (though the resulting profiles
must be wrong). We noticed it because of a bad interaction with stack
barriers. Specifically, once we get the next frame size wrong, we also
get the location of its LR wrong. If we happen to get a stack slot
that contains a stale stack barrier LR (for a stack barrier we already
hit) and hasn't been overwritten with something else as we re-grew the
stack, gentraceback will fail with a "found next stack barrier at ..."
error, pointing at the slot that it thinks is an LR, but isn't.

Fixes #15138.

Updates #15313 (might fix it).

Change-Id: I13cfa322b44c0c2f23ac2b3d03e12631e4a6406b
Reviewed-on: https://go-review.googlesource.com/23291
Run-TryBot: Austin Clements 
TryBot-Result: Gobot Gobot 
Reviewed-by: Rick Hudson 
Reviewed-by: Cherry Zhang

runtime: print PC, not the counter, for a cgo traceback

2016-05-18T23:47:13+00:00

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

runtime: stop traceback at foreign function

2016-05-06T00:54:25+00:00

This can only happen when profiling and there is foreign code
at the top of the g0 stack but we're not in cgo.
That in turn only happens with the race detector.

Fixes #13568.

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

cmd/cgo, runtime, runtime/cgo: use cgo context function

2016-04-29T22:07:36+00:00

Add support for the context function set by runtime.SetCgoTraceback.
The context function was added in CL 17761, without support.
This CL is the support.

This CL has not been tested for real C code, as a working context
function for C code requires unwind support that does not seem to exist.
I wanted to get the CL out before the freeze.

I apologize for the length of this CL.  It's mostly plumbing, but
unfortunately the plumbing is processor-specific.

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