runtime: shrinking the stack during a system call may cause a corrupt address

[ianlancetaylor]

This is a spinoff of #10303 .

In a function like this:

func F() {
var a [10]byte
syscall.Read(0, a[:])
}

a does not escape and is therefore allocated on the stack. The call to syscall.Read may block. If a GC occurs while it is blocking, the GC may decide to shrink the stack. Shrinking the stack will move a. This will cause the read call to corrupt random memory when it finally returns.

This is a supposition based on looking at the code. I have no actual test case.

We do not want to treat pointers to syscall functions as causing the pointers to escape. That would force values into the heap unnecessarily. We know that syscall functions on Unix systems never cause the pointers to escape.

Therefore, we need some way to prevent the stack from shrinking while the function is in a system call. One simple approach would be to also prevent the stack from shrinking while in a cgo call: not shrink the stack if the goroutine status is Gsyscall. I don't think that would be too bad--I doubt many goroutines hang in cgo calls with a large stack.

Anyhow, this issue has to be resolved before the 1.5 release, either by deciding that it is not a problem, or by fixing it.

[randall77]

We don't shrink stacks if they are in syscall, so I think this is not a bug.

src/runtime/stack1.go:809
// We can't copy the stack if we're in a syscall.
// The syscall might have pointers into the stack.
if gp.syscallsp != 0 {
return
}

I had some ideas about how to shrink without copying (use a buddy list allocator for stacks). But the complexity seemed unnecessary. The only case it would matter is when the goroutine used a large stack, then popped most of it, then made a syscall.

[ianlancetaylor]

Thanks, sorry I missed that.