Descriptionruntime: avoid gentraceback of self on user goroutine stack
Gentraceback may grow the stack.
One of the gentraceback wrappers may grow the stack.
One of the gentraceback callback calls may grow the stack.
Various stack pointers are stored in various stack locations
as type uintptr during the execution of these calls.
If the stack does grow, these stack pointers will not be
updated and will start trying to decode stack memory that
is no longer valid.
It may be possible to change the type of the stack pointer
variables to be unsafe.Pointer, but that's pretty subtle and
may still have problems, even if we catch every last one.
An easier, more obviously correct fix is to require that
gentraceback of the currently running goroutine must run
on the g0 stack, not on the goroutine's own stack.
Not doing this causes faults when you set
StackFromSystem = 1
StackFaultOnFree = 1
The new check in gentraceback will catch future lapses.
The more general problem is calling getcallersp but then
calling a function that might relocate the stack, which would
invalidate the result of getcallersp. Add note to stubs.go
declaration of getcallersp explaining the problem, and
check all existing calls to getcallersp. Most needed fixes.
This affects Callers, Stack, and nearly all the runtime
profiling routines. It does not affect stack copying directly
nor garbage collection.
Patch Set 1 #Patch Set 2 : diff -r 1fdfd7dfaedb1b7702141617e621ab7328a236a1 https://code.google.com/p/go/ #Patch Set 3 : diff -r 1fdfd7dfaedb1b7702141617e621ab7328a236a1 https://code.google.com/p/go/ #Patch Set 4 : diff -r 53ebc70d4e9f843cb718f173e3225e9a0fc121e2 https://code.google.com/p/go/ #
Total comments: 4
Patch Set 5 : diff -r c3de8d47b28245a3fd5e8bdf2520046a16239fc5 https://code.google.com/p/go/ #
MessagesTotal messages: 5
|
|||||||||||||||||||||||||||||||||||||