Debugging an evil Go runtime bug - https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ …
-
-
Replying to @msinilo
That was an awesome investigation. My conclusion would be that the Go Runtime is unnecessarily creating stacks without guard pages, thus bringing back Stack Clash - and this bug was just a side-effect
1 reply 0 retweets 3 likes -
Replying to @BruceDawson0xB @msinilo
I believe it's by design - Go uses very small growable stacks, and the overhead of allocating *and* marking the entire page after each stack as unmapped would significantly impact performance/memory on some workloads.
1 reply 0 retweets 0 likes -
It does sound like it's by design, I just think it's excessively risky design. The Go Runtime also works around its own scheduler weaknesses by raising windows timer frequency. It seems very old-school for a newish language
1 reply 0 retweets 1 like
Go shouldn't be overflowing its stacks since it dynamically grows them. The stupid thing here was calling into C code without switching into a C-compatible stack. Last time I found a Go runtime bug it was in the (normal) C interop too. Go has serious issues with C FFI.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.