code review 4230044: runtime: fix signal stack bug

runtime: fix signal stack bug

In CL 4188061 I changed malg to allocate the requested
number of bytes n, not n+StackGuard, so that the
allocations would use rounder numbers.

The allocation of the signal stack asks for 32k and
then used g->stackguard as the base, but g->stackguard
is StackGuard bytes above the base.  Previously, asking
for 32k meant getting 32k+StackGuard bytes, so using
g->stackguard as the base was safe.  Now, the actual base
must be computed, so that the signal handler does not
run StackGuard bytes past the top of the stack.

Was causing flakiness mainly in programs that use the
network, because they sometimes write to closed network
connections, causing SIGPIPEs.  Was also causing problems
in the doc/progs test.

Also fix Makefile so that changes to stack.h trigger rebuild.

[rsc, 2011-02-24 21:34:45]

Hello bradfitzgo, r (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg

[r2, 2011-02-24 21:44:16]

LGTM

[rsc, 2011-02-24 21:46:47]

*** Submitted as 7bb9f06500d3 ***

runtime: fix signal stack bug

In CL 4188061 I changed malg to allocate the requested
number of bytes n, not n+StackGuard, so that the
allocations would use rounder numbers.

The allocation of the signal stack asks for 32k and
then used g->stackguard as the base, but g->stackguard
is StackGuard bytes above the base.  Previously, asking
for 32k meant getting 32k+StackGuard bytes, so using
g->stackguard as the base was safe.  Now, the actual base
must be computed, so that the signal handler does not
run StackGuard bytes past the top of the stack.

Was causing flakiness mainly in programs that use the
network, because they sometimes write to closed network
connections, causing SIGPIPEs.  Was also causing problems
in the doc/progs test.

Also fix Makefile so that changes to stack.h trigger rebuild.

R=bradfitzgo, r, r2
CC=golang-dev
http://codereview.appspot.com/4230044