These stacks are not large at all, so the problem is not actual stack overflow, but a false report of stack overflow.

I can imagine a possibility: if there are both a synchronous preemption request (by clobbering the stack guard) and an asynchronous one (by signal), and the goroutine in a function prologue first sees the clobbered stack guard, so it will call morestack. If the signal lands after the CMP instruction but before the call to morestack, it will be asynchronously preempted, enter the scheduler. When it is resumed, the scheduler clears the preemption request, unclobbers the stack guard. But the resumed goroutine will still call morestack (as it has passed the CMP instruction). morestack will, as there is no preemption request, double the stack unnecessarily. If this happens multiple times, the stack may grow too big, although only a small amount is actually used.

I let it print the current stack bounds in the stack-too-large error message, and the stack is indeed quite large, with only a small amount used:

runtime: goroutine stack exceeds 250000000-byte limit
	sp=0x1847dad8 stack=[0x10480000, 0x18480000]
fatal error: stack overflow

In theory this can happen on other platforms. Not sure why this is only seen on the ARM builder.

Maybe we want to disable async preemption in function prologue between the CMP instruction and the call to morestack? As it will call morestack, it will be preempted anyway.

@cherrymui That sounds like a good idea.

I think we might have to start at the load of the stack guard, as the CMP result is predestined at that point. But then maybe we need to only prevent async preemption if that loaded value is in fact the preempted guard.

Tricky.

Change https://golang.org/cl/207350 mentions this issue: cmd/internal/obj: mark split-stack prologue nonpreemptible

Change https://golang.org/cl/207351 mentions this issue: runtime: print more information on stack overflow

Change https://golang.org/cl/207349 mentions this issue: cmd/internal/obj, runtime: use register map to mark unsafe points

See also #35784.

Should we also close #35784?

Yeah, I think we can close that.