7 ms·

cool... what does this mean the best linter / correctness checking is at the moment? I have some code that eventually core dumps and honestly I don't know what

cool... what does this mean the best linter / correctness checking is at the moment? I have some code that eventually core dumps and honestly I don't know what I'm doing wrong, and neither do any golang tools I've tried :( maaaaaybe there's something that'll check that your code never closes a channel or always blocks after a specific order of events happens...

mseepgood 3y ago
I don't think a pure Go program can core dump, unless you use Cgo (wrongly) or unsafe. It can only panic.
- yencabulator 3y ago
  Races between goroutines can corrupt memory. E.g. manipulate a map from two goroutines and you can wreck its internal state.
  - mutatio 3y ago
    Can this actually manifest? Even without the -race flag I think maps are a special case which will panic with a concurrent mutation error if access isn't synchronized.
    - yencabulator 3y ago
      Another example: thread A toggles an interface variable between two types, thread B calls a method on it. You can get the method of type X called with a receiver of type Y.
    - tgv 3y ago
      I've had that, and it did panic.
    - masklinn 3y ago
      > Can this actually manifest? Yes. Per rsc (https://research.swtch.com/gorace https://research.swtch.com/gorace) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https://github.com/netanel01/ctf-writeups/blob/master/googlectf/2019/pwn_gomium/README.md https://github.com/netanel01/ctf-writeups/blob/master/google... These are not idle fancies, there are lots of ways to unwittingly get data races in go: https://www.uber.com/blog/data-race-patterns-in-go https://www.uber.com/blog/data-race-patterns-in-go.
      - tialaramex 3y ago
        It's interesting that the 2010 article you linked suggests they might consider improving this but nope, Go 1.0 and the Go people use today just basically takes the same attitude as C and C++ albeit with a small nuance. In C and C++ SC/DRF (Sequentially Consistent if Data Race Free) turns into "All data races are Undefined Behaviour, game over, you lose". In Go SC/DRF turns into "All data races on complex types are Undefined Behaviour, game over, you lose". If you race e.g. a simple integer counter, it's damaged and you ought not to use it because it might be anything now, but Go isn't reduced to Undefined Behaviour immediately for this seemingly trivial mishap (whereas C and C++ are)
        yencabulator 3y ago
        Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to, but once you corrupt the map data structure, weird things can happen. Trying to contain that explosion isn't necessarily "better", as it would make maps slower / take up more memory / etc.
        masklinn 3y ago
        > Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to The reasons C compilers “tend to go out of their way to make weird things happen” is they optimise extremely aggressively, and optimisations are predicated upon the code being valid (not having UBs). Go barely optimises at all, and does not have that many UBs which could send the optimiser in a frenzy.
- adonovan 3y ago
  There are ways a Go program can fatal: by running out of heap, or stack, by corrupting variables by racing writes, by deadlocking, by misuse of reflect or unsafe, and so on.
  - deleted 3y ago
    [deleted]
- DominoTree 3y ago
  I’ve seen it happen before because the stdlib actually directly just makes POSIX syscalls for a lot of things by default instead of using the native Go implementations and so you’re implicitly reliant on C code

mseepgood 3y ago

I don't think a pure Go program can core dump, unless you use Cgo (wrongly) or unsafe. It can only panic.

yencabulator 3y ago
Races between goroutines can corrupt memory. E.g. manipulate a map from two goroutines and you can wreck its internal state.
- mutatio 3y ago
  Can this actually manifest? Even without the -race flag I think maps are a special case which will panic with a concurrent mutation error if access isn't synchronized.
  - yencabulator 3y ago
    Another example: thread A toggles an interface variable between two types, thread B calls a method on it. You can get the method of type X called with a receiver of type Y.
  - tgv 3y ago
    I've had that, and it did panic.
  - masklinn 3y ago
    > Can this actually manifest? Yes. Per rsc (https://research.swtch.com/gorace https://research.swtch.com/gorace) > In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program. That races undermine memory safety in go has been used in CTFs: https://github.com/netanel01/ctf-writeups/blob/master/googlectf/2019/pwn_gomium/README.md https://github.com/netanel01/ctf-writeups/blob/master/google... These are not idle fancies, there are lots of ways to unwittingly get data races in go: https://www.uber.com/blog/data-race-patterns-in-go https://www.uber.com/blog/data-race-patterns-in-go.
    - tialaramex 3y ago
      It's interesting that the 2010 article you linked suggests they might consider improving this but nope, Go 1.0 and the Go people use today just basically takes the same attitude as C and C++ albeit with a small nuance. In C and C++ SC/DRF (Sequentially Consistent if Data Race Free) turns into "All data races are Undefined Behaviour, game over, you lose". In Go SC/DRF turns into "All data races on complex types are Undefined Behaviour, game over, you lose". If you race e.g. a simple integer counter, it's damaged and you ought not to use it because it might be anything now, but Go isn't reduced to Undefined Behaviour immediately for this seemingly trivial mishap (whereas C and C++ are)
      - yencabulator 3y ago
        Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to, but once you corrupt the map data structure, weird things can happen. Trying to contain that explosion isn't necessarily "better", as it would make maps slower / take up more memory / etc.
        masklinn 3y ago
        > Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to The reasons C compilers “tend to go out of their way to make weird things happen” is they optimise extremely aggressively, and optimisations are predicated upon the code being valid (not having UBs). Go barely optimises at all, and does not have that many UBs which could send the optimiser in a frenzy.
adonovan 3y ago
There are ways a Go program can fatal: by running out of heap, or stack, by corrupting variables by racing writes, by deadlocking, by misuse of reflect or unsafe, and so on.
- deleted 3y ago
  [deleted]
DominoTree 3y ago
I’ve seen it happen before because the stdlib actually directly just makes POSIX syscalls for a lot of things by default instead of using the native Go implementations and so you’re implicitly reliant on C code