This provides a way to generate core dumps when people need them.
The settings are:
GOTRACEBACK=0 no traceback on panic, just exit
GOTRACEBACK=1 default - traceback on panic, then exit
GOTRACEBACK=2 traceback including runtime frames on panic, then exit
GOTRACEBACK=crash traceback including runtime frames on panic, then crash
Fixes#3257.
R=golang-dev, devon.odell, r, daniel.morsing, ality
CC=golang-dev
https://golang.org/cl/7666044
The issue was that scvg is assigned *after* the scavenger goroutine is started,
so when the scavenger calls entersyscall() the g==scvg check can fail.
Fixes#5025.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7629045
Otherwise the next goroutine run on the m
can get inadvertently locked if it executes a cgo call
that turns on the internal lock.
While we're here, fix the cgo panic unwind to
decrement m->ncgo like the non-panic unwind does.
Fixes#4971.
R=golang-dev, iant, dvyukov
CC=golang-dev
https://golang.org/cl/7627043
The deadlock episodically occurs on misc/cgo/test/TestCthread.
The problem is that starttheworld() leaves some P's with local work
without M's. Then all active M's enter into syscalls, but reject to
wake another M's due to the following check (both in entersyscallblock() and in retake()):
if(p->runqhead == p->runqtail &&
runtime·atomicload(&runtime·sched.nmspinning) +
runtime·atomicload(&runtime·sched.npidle) > 0)
continue;
R=rsc
CC=golang-dev
https://golang.org/cl/7424054
broke arm garbage collector
traceback_arm fails with a missing pc. It needs CL 7494043.
But that only makes the build break later, this time with
"invalid freelist". Roll back until it can be fixed correctly.
««« original CL description
runtime: restrict stack root scan to locals and arguments
R=rsc
CC=golang-dev
https://golang.org/cl/7301062
»»»
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/7493044
Putting the M initialization in multiple places will not scale.
Various code assumes mstart is the start already. Make it so.
R=golang-dev, devon.odell
CC=golang-dev
https://golang.org/cl/7420048
The naming in this package is a disaster.
Make it all consistent.
Remove some 'static' from functions that will
be referred to from other files soon.
This CL is purely renames using global search and replace.
Submitting separately so that real changes will not
be drowned out by these renames in future CLs.
TBR=iant
CC=golang-dev
https://golang.org/cl/7416046
add per-P cache of dead G's
add global runnable queue (not used for now)
add list of idle P's (not used for now)
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7397061
mpreinit() is called on the parent thread and with mcache (can allocate memory),
minit() is called on the child thread and can not allocate memory.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7389043
The removed code leads to the situation when M executes the same locked G again
and again.
This is https://golang.org/cl/7310096 but with return instead of break
in the nested switch.
Fixes#4820.
R=golang-dev, alex.brainman, rsc
CC=golang-dev
https://golang.org/cl/7304102
broke windows build
««« original CL description
runtime: ensure forward progress of runtime.Gosched() for locked goroutines
The removed code leads to the situation when M executes the same locked G again and again.
Fixes#4820.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7310096
»»»
TBR=dvyukov
CC=golang-dev
https://golang.org/cl/7343050
Arguably if this happens the program is buggy anyway,
but letting the panic continue looks better than interrupting it.
Otherwise things like this are possible, and confusing:
$ go run x.go
panic: $ echo $?
0
$
Fixes#3934.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/7322083
The removed code leads to the situation when M executes the same locked G again and again.
Fixes#4820.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7310096
No code changes.
This is mainly in preparation to scheduler changes,
oldstack/newstack are not related to scheduling.
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7311085
Removes limit on maximum number of goroutines ever existed.
code.google.com/p/goexecutor tests now pass successfully.
Also slightly improves performance.
Before: $ time ./flate.test -test.short
real 0m9.314s
After: $ time ./flate.test -test.short
real 0m8.958s
Fixes#4286.
The runtime is built from llvm rev 174312.
R=rsc
CC=golang-dev
https://golang.org/cl/7218044
* Separate internal and external LockOSThread, for cgo safety.
* Show goroutine that made faulting cgo call.
* Never start a panic due to a signal caused by a cgo call.
Fixes#3774.
Fixes#3775.
Fixes#3797.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/7228081
Binary data in mprof.goc may prevent the garbage collector from freeing
memory blocks. This patch replaces all calls to runtime·mallocgc() with
calls to an allocator private to mprof.goc, thus making the private
memory invisible to the garbage collector. The addrhash variable is
moved outside of the .bss section.
R=golang-dev, dvyukov, rsc, minux.ma
CC=dave, golang-dev, remyoudompheng
https://golang.org/cl/7135063
Useful for debugging of runtime bugs.
+ Do not print "stack segment boundary" unless GOTRACEBACK>1.
+ Do not traceback system goroutines unless GOTRACEBACK>1.
R=rsc, minux.ma
CC=golang-dev
https://golang.org/cl/7098050
Garbage collection code (to be merged later) is calling functions
which have many local variables. This increases the probability that
the stack capacity won't be big enough to hold the local variables.
So, start gc() on a bigger stack to eliminate a potentially large number
of calls to runtime·morestack().
R=rsc, remyoudompheng, dsymonds, minux.ma, iant, iant
CC=golang-dev
https://golang.org/cl/6846044
This CL makes the runtime understand that the type of
the len or cap of a map, slice, or string is 'int', not 'int32',
and it is also careful to distinguish between function arguments
and results of type 'int' vs type 'int32'.
In the runtime, the new typedefs 'intgo' and 'uintgo' refer
to Go int and uint. The C types int and uint continue to be
unavailable (cause intentional compile errors).
This CL does not change the meaning of int, but it should make
the eventual change of the meaning of int on amd64 a bit
smoother.
Update #2188.
R=iant, r, dave, remyoudompheng
CC=golang-dev
https://golang.org/cl/6551067
The change is a preparation for the new scheduler.
It introduces runtime.park() function,
that will atomically unlock the mutex and park the goroutine.
It will allow to remove the racy readyonstop flag
that is difficult to implement w/o the global scheduler mutex.
R=rsc, remyoudompheng, dave
CC=golang-dev
https://golang.org/cl/6501077
Move panic/defer/recover-related stuff from proc.c/runtime.c to a new file panic.c.
No semantic changes.
proc.c is 1800+ LOC and is a bit difficult to work with.
R=golang-dev, dave, r
CC=golang-dev
https://golang.org/cl/6343071
1. Rename 'g' and 'm' local vars to 'gp' and 'mp' (convention already used in some functions)
'g' and 'm' are global vars that mean current goroutine and current machine,
when they are shadowed by local vars, it's confusing, no ability to debug log both, etc.
2. White-space shuffling.
No semantic changes.
In preparation to bigger changes.
R=golang-dev, dave
CC=golang-dev
https://golang.org/cl/6355061
Parallel GC needs to know in advance how many helper threads will be there.
Hopefully it's the last patch before I can tackle parallel sweep phase.
The benchmarks are unaffected.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6200064
Not a complete fix for issue 3342, but fixes the trivial case.
There may still be a race in the instants before and after
a scavenger-induced garbage collection.
Intended to be "obviously safe": a call to runtime·gosched
before main.main is no different than a call to runtime.Gosched
at the beginning of main.main, and it is (or had better be)
safe to call runtime.Gosched at any point during main.
Update #3342.
R=iant
CC=golang-dev
https://golang.org/cl/5919052
Breaks closure test when GOMAXPROCS=2 or more.
««« original CL description
runtime: restore deadlock detection in the simplest case.
Fixes#3342.
R=iant, r, dave, rsc
CC=golang-dev, remy
https://golang.org/cl/5844051
»»»
R=rsc
CC=golang-dev
https://golang.org/cl/5924045
