runtime: spanBytesAlloc underflow on windows 32bit

[fmzquant]

this happened in windows 32 bit some times, never happen in linux 64 bit,
Very difficult to reproduce.

[fmzquant]

go version is 1.7.3

[odeke-em]

/cc @aclements @RLH

[aclements]

@botvs, thanks for the report. I think I know what's going on. You mentioned that this is "very difficult to reproduce", which suggests that you have at least been able to reproduce it. If I sent you a patch to add some additional debugging to the runtime to confirm my suspicion, how hard do you think it would be for you to test?

[aclements]

As for what I think it going on: if mcentral.cacheSpan is preempted by mark termination between the call to deductSweepCredit and the call to reimbuseSweepCredit, then mheap_.spanBytesAlloc will be zeroed and reimbuseSweepCredit will underflow. Probably the right fix is for reimbuseSweepCredit to check if we're still in the same GC cycle as the deductSweepCredit it's supposed to be balanced with and just do nothing if we're not.

[aclements]

On the other hand, mcentral.cacheSpan happens while g.m.locks != 0, so it's not, in fact, preemptible.

[aclements]

Another plausible but incorrect theory is that mheap_.spanBytesAlloc wasn't 8-byte aligned, since 1.7.3's runtime/internal/atomic.Xadd64 didn't check this (it does on master), but it appears it is in fact aligned. (And I'm pretty sure Xadd64 genuinely doesn't require alignment on 386 like the other 64-bit atomics do, though that's hard to confirm.)

[fmzquant]

I'm sorry, I just saw this. How to patch it ?

[aclements]

@botvs, are you set up to compile your own Go toolchain? If not, that's the first step to patching. If so, I can upload a change to the code review tool and you can patch that in pretty easily. I'll have to figure out exactly what debug info I want, though, since none of my theories so far have actually panned out.

[aclements]

@botvs, ping.