2009-05-08 16:55:45 -06:00
|
|
|
// Copyright 2009 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
/*
|
2013-03-14 23:11:03 -06:00
|
|
|
Package runtime contains operations that interact with Go's runtime system,
|
|
|
|
such as functions to control goroutines. It also includes the low-level type information
|
|
|
|
used by the reflect package; see reflect's documentation for the programmable
|
|
|
|
interface to the run-time type system.
|
|
|
|
|
|
|
|
Environment Variables
|
|
|
|
|
|
|
|
The following environment variables ($name or %name%, depending on the host
|
|
|
|
operating system) control the run-time behavior of Go programs. The meanings
|
|
|
|
and use may change from release to release.
|
|
|
|
|
|
|
|
The GOGC variable sets the initial garbage collection target percentage.
|
|
|
|
A collection is triggered when the ratio of freshly allocated data to live data
|
|
|
|
remaining after the previous collection reaches this percentage. The default
|
|
|
|
is GOGC=100. Setting GOGC=off disables the garbage collector entirely.
|
|
|
|
The runtime/debug package's SetGCPercent function allows changing this
|
|
|
|
percentage at run time. See http://golang.org/pkg/runtime/debug/#SetGCPercent.
|
|
|
|
|
2013-06-28 08:37:06 -06:00
|
|
|
The GODEBUG variable controls debug output from the runtime. GODEBUG value is
|
|
|
|
a comma-separated list of name=val pairs. Supported names are:
|
2013-08-13 14:30:55 -06:00
|
|
|
|
2013-12-06 15:40:45 -07:00
|
|
|
allocfreetrace: setting allocfreetrace=1 causes every allocation to be
|
|
|
|
profiled and a stack trace printed on each object's allocation and free.
|
|
|
|
|
|
|
|
efence: setting efence=1 causes the allocator to run in a mode
|
|
|
|
where each object is allocated on a unique page and addresses are
|
|
|
|
never recycled.
|
|
|
|
|
2013-08-13 14:30:55 -06:00
|
|
|
gctrace: setting gctrace=1 causes the garbage collector to emit a single line to standard
|
|
|
|
error at each collection, summarizing the amount of memory collected and the
|
|
|
|
length of the pause. Setting gctrace=2 emits the same summary but also
|
|
|
|
repeats each collection.
|
|
|
|
|
2014-03-25 15:11:34 -06:00
|
|
|
gcdead: setting gcdead=1 causes the garbage collector to clobber all stack slots
|
|
|
|
that it thinks are dead.
|
|
|
|
|
2014-10-28 19:53:31 -06:00
|
|
|
invalidptr: defaults to invalidptr=1, causing the garbage collector and stack
|
|
|
|
copier to crash the program if an invalid pointer value (for example, 1)
|
|
|
|
is found in a pointer-typed location. Setting invalidptr=0 disables this check.
|
|
|
|
This should only be used as a temporary workaround to diagnose buggy code.
|
|
|
|
The real fix is to not store integers in pointer-typed locations.
|
|
|
|
|
2013-08-13 14:30:55 -06:00
|
|
|
scheddetail: setting schedtrace=X and scheddetail=1 causes the scheduler to emit
|
|
|
|
detailed multiline info every X milliseconds, describing state of the scheduler,
|
|
|
|
processors, threads and goroutines.
|
2013-03-14 23:11:03 -06:00
|
|
|
|
2013-12-06 15:40:45 -07:00
|
|
|
schedtrace: setting schedtrace=X causes the scheduler to emit a single line to standard
|
|
|
|
error every X milliseconds, summarizing the scheduler state.
|
2013-12-03 15:42:38 -07:00
|
|
|
|
2014-08-25 13:30:39 -06:00
|
|
|
scavenge: scavenge=1 enables debugging mode of heap scavenger.
|
|
|
|
|
2013-03-14 23:11:03 -06:00
|
|
|
The GOMAXPROCS variable limits the number of operating system threads that
|
|
|
|
can execute user-level Go code simultaneously. There is no limit to the number of threads
|
|
|
|
that can be blocked in system calls on behalf of Go code; those do not count against
|
|
|
|
the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes
|
|
|
|
the limit.
|
|
|
|
|
|
|
|
The GOTRACEBACK variable controls the amount of output generated when a Go
|
|
|
|
program fails due to an unrecovered panic or an unexpected runtime condition.
|
|
|
|
By default, a failure prints a stack trace for every extant goroutine, eliding functions
|
|
|
|
internal to the run-time system, and then exits with exit code 2.
|
|
|
|
If GOTRACEBACK=0, the per-goroutine stack traces are omitted entirely.
|
|
|
|
If GOTRACEBACK=1, the default behavior is used.
|
|
|
|
If GOTRACEBACK=2, the per-goroutine stack traces include run-time functions.
|
|
|
|
If GOTRACEBACK=crash, the per-goroutine stack traces include run-time functions,
|
|
|
|
and if possible the program crashes in an operating-specific manner instead of
|
|
|
|
exiting. For example, on Unix systems, the program raises SIGABRT to trigger a
|
|
|
|
core dump.
|
|
|
|
|
|
|
|
The GOARCH, GOOS, GOPATH, and GOROOT environment variables complete
|
|
|
|
the set of Go environment variables. They influence the building of Go programs
|
|
|
|
(see http://golang.org/cmd/go and http://golang.org/pkg/go/build).
|
|
|
|
GOARCH, GOOS, and GOROOT are recorded at compile time and made available by
|
|
|
|
constants or functions in this package, but they do not influence the execution
|
|
|
|
of the run-time system.
|
2009-11-05 16:37:55 -07:00
|
|
|
*/
|
2009-05-08 16:55:45 -06:00
|
|
|
package runtime
|
|
|
|
|
|
|
|
// Caller reports file and line number information about function invocations on
|
2012-01-04 15:06:54 -07:00
|
|
|
// the calling goroutine's stack. The argument skip is the number of stack frames
|
2012-05-24 15:15:43 -06:00
|
|
|
// to ascend, with 0 identifying the caller of Caller. (For historical reasons the
|
2012-04-09 17:47:57 -06:00
|
|
|
// meaning of skip differs between Caller and Callers.) The return values report the
|
2009-05-08 16:55:45 -06:00
|
|
|
// program counter, file name, and line number within the file of the corresponding
|
|
|
|
// call. The boolean ok is false if it was not possible to recover the information.
|
2014-08-28 08:46:59 -06:00
|
|
|
func Caller(skip int) (pc uintptr, file string, line int, ok bool) {
|
|
|
|
// Ask for two PCs: the one we were asked for
|
|
|
|
// and what it called, so that we can see if it
|
|
|
|
// "called" sigpanic.
|
|
|
|
var rpc [2]uintptr
|
runtime: convert traceback*.c to Go
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
2014-09-02 13:12:53 -06:00
|
|
|
if callers(1+skip-1, &rpc[0], 2) < 2 {
|
2014-08-28 08:46:59 -06:00
|
|
|
return
|
|
|
|
}
|
|
|
|
f := findfunc(rpc[1])
|
|
|
|
if f == nil {
|
|
|
|
// TODO(rsc): Probably a bug?
|
|
|
|
// The C version said "have retpc at least"
|
|
|
|
// but actually returned pc=0.
|
|
|
|
ok = true
|
|
|
|
return
|
|
|
|
}
|
|
|
|
pc = rpc[1]
|
|
|
|
xpc := pc
|
|
|
|
g := findfunc(rpc[0])
|
runtime: convert traceback*.c to Go
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
2014-09-02 13:12:53 -06:00
|
|
|
// All architectures turn faults into apparent calls to sigpanic.
|
|
|
|
// If we see a call to sigpanic, we do not back up the PC to find
|
|
|
|
// the line number of the call instruction, because there is no call.
|
2014-09-03 11:02:48 -06:00
|
|
|
if xpc > f.entry && (g == nil || g.entry != funcPC(sigpanic)) {
|
2014-08-28 08:46:59 -06:00
|
|
|
xpc--
|
|
|
|
}
|
[dev.cc] runtime: delete scalararg, ptrarg; rename onM to systemstack
Scalararg and ptrarg are not "signal safe".
Go code filling them out can be interrupted by a signal,
and then the signal handler runs, and if it also ends up
in Go code that uses scalararg or ptrarg, now the old
values have been smashed.
For the pieces of code that do need to run in a signal handler,
we introduced onM_signalok, which is really just onM
except that the _signalok is meant to convey that the caller
asserts that scalarg and ptrarg will be restored to their old
values after the call (instead of the usual behavior, zeroing them).
Scalararg and ptrarg are also untyped and therefore error-prone.
Go code can always pass a closure instead of using scalararg
and ptrarg; they were only really necessary for C code.
And there's no more C code.
For all these reasons, delete scalararg and ptrarg, converting
the few remaining references to use closures.
Once those are gone, there is no need for a distinction between
onM and onM_signalok, so replace both with a single function
equivalent to the current onM_signalok (that is, it can be called
on any of the curg, g0, and gsignal stacks).
The name onM and the phrase 'm stack' are misnomers,
because on most system an M has two system stacks:
the main thread stack and the signal handling stack.
Correct the misnomer by naming the replacement function systemstack.
Fix a few references to "M stack" in code.
The main motivation for this change is to eliminate scalararg/ptrarg.
Rick and I have already seen them cause problems because
the calling sequence m.ptrarg[0] = p is a heap pointer assignment,
so it gets a write barrier. The write barrier also uses onM, so it has
all the same problems as if it were being invoked by a signal handler.
We worked around this by saving and restoring the old values
and by calling onM_signalok, but there's no point in keeping this nice
home for bugs around any longer.
This CL also changes funcline to return the file name as a result
instead of filling in a passed-in *string. (The *string signature is
left over from when the code was written in and called from C.)
That's arguably an unrelated change, except that once I had done
the ptrarg/scalararg/onM cleanup I started getting false positives
about the *string argument escaping (not allowed in package runtime).
The compiler is wrong, but the easiest fix is to write the code like
Go code instead of like C code. I am a bit worried that the compiler
is wrong because of some use of uninitialized memory in the escape
analysis. If that's the reason, it will go away when we convert the
compiler to Go. (And if not, we'll debug it the next time.)
LGTM=khr
R=r, khr
CC=austin, golang-codereviews, iant, rlh
https://golang.org/cl/174950043
2014-11-12 12:54:31 -07:00
|
|
|
file, line32 := funcline(f, xpc)
|
|
|
|
line = int(line32)
|
2014-08-28 08:46:59 -06:00
|
|
|
ok = true
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2014-10-29 13:14:04 -06:00
|
|
|
// Callers fills the slice pc with the return program counters of function invocations
|
2010-03-23 21:48:23 -06:00
|
|
|
// on the calling goroutine's stack. The argument skip is the number of stack frames
|
2012-05-24 15:15:43 -06:00
|
|
|
// to skip before recording in pc, with 0 identifying the frame for Callers itself and
|
|
|
|
// 1 identifying the caller of Callers.
|
2010-03-23 21:48:23 -06:00
|
|
|
// It returns the number of entries written to pc.
|
2014-10-29 13:14:04 -06:00
|
|
|
//
|
|
|
|
// Note that since each slice entry pc[i] is a return program counter,
|
|
|
|
// looking up the file and line for pc[i] (for example, using (*Func).FileLine)
|
|
|
|
// will return the file and line number of the instruction immediately
|
|
|
|
// following the call.
|
|
|
|
// To look up the file and line number of the call itself, use pc[i]-1.
|
|
|
|
// As an exception to this rule, if pc[i-1] corresponds to the function
|
|
|
|
// runtime.sigpanic, then pc[i] is the program counter of a faulting
|
|
|
|
// instruction and should be used without any subtraction.
|
2014-08-28 08:46:59 -06:00
|
|
|
func Callers(skip int, pc []uintptr) int {
|
|
|
|
// runtime.callers uses pc.array==nil as a signal
|
|
|
|
// to print a stack trace. Pick off 0-length pc here
|
|
|
|
// so that we don't let a nil pc slice get to it.
|
|
|
|
if len(pc) == 0 {
|
|
|
|
return 0
|
|
|
|
}
|
runtime: convert traceback*.c to Go
The two converted files were nearly identical.
Instead of continuing that duplication, I merged them
into a single traceback.go.
Tested on arm, amd64, amd64p32, and 386.
LGTM=r
R=golang-codereviews, remyoudompheng, dave, r
CC=dvyukov, golang-codereviews, iant, khr
https://golang.org/cl/134200044
2014-09-02 13:12:53 -06:00
|
|
|
return callers(skip, &pc[0], len(pc))
|
2014-08-28 08:46:59 -06:00
|
|
|
}
|
|
|
|
|
2010-03-17 00:10:33 -06:00
|
|
|
// GOROOT returns the root of the Go tree.
|
|
|
|
// It uses the GOROOT environment variable, if set,
|
|
|
|
// or else the root used during the Go build.
|
|
|
|
func GOROOT() string {
|
2014-08-28 08:46:59 -06:00
|
|
|
s := gogetenv("GOROOT")
|
2010-03-17 00:10:33 -06:00
|
|
|
if s != "" {
|
|
|
|
return s
|
|
|
|
}
|
|
|
|
return defaultGoroot
|
|
|
|
}
|
|
|
|
|
|
|
|
// Version returns the Go tree's version string.
|
2014-05-20 12:41:24 -06:00
|
|
|
// It is either the commit hash and date at the time of the build or,
|
|
|
|
// when possible, a release tag like "go1.3".
|
2010-09-02 12:19:12 -06:00
|
|
|
func Version() string {
|
|
|
|
return theVersion
|
|
|
|
}
|
|
|
|
|
2012-02-16 14:49:41 -07:00
|
|
|
// GOOS is the running program's operating system target:
|
2010-09-02 12:19:12 -06:00
|
|
|
// one of darwin, freebsd, linux, and so on.
|
|
|
|
const GOOS string = theGoos
|
|
|
|
|
2012-02-16 14:49:41 -07:00
|
|
|
// GOARCH is the running program's architecture target:
|
2010-09-02 12:19:12 -06:00
|
|
|
// 386, amd64, or arm.
|
|
|
|
const GOARCH string = theGoarch
|