4 ms·

It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: htt

It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people: https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9ee9303cde7bd6b/src/runtime/sys_linux_amd64.s#L139-L143 https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9... https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

aeontech 7y ago
That debug report was incredible, I have to say. Hats off to the author for their patience.
rob74 7y ago
I don't think this example justifies the expression "incredibly broken assumptions", I would rather call it an "incredible corner case"...
- kevingadd 7y ago
  Making assumptions about the stack frame size of third-party code is incredibly broken. You have no way to make any guarantees about it and primitives like alloca mean you can't even be sure the stack size will be the same across multiple calls.
  - amscanne 7y ago
    The VDSO isn’t really any third-party code. It’s very surprising for it to do a stack probe. Though obviously it’s possible, and falls on the runtime to handle (so it’s a legit bug). But.. nearly every “runtime” makes stack assumptions. They usually just have enough slack that it doesn’t matter. E.g. musl has an 80k stack by default — is it still “incredibly broken” if the VDSO needs > 80k? No. While the VDSO doesn’t have an explicit stack requirement, it’s definitely implicit that it will use a small, reasonable amount.