Michael Pratt
Michael Pratt
Could you collect a core dump (`ulimit -c unlimited` and set `GOTRACEBACK=crash`)? Then in gdb running `thread apply all bt` should show where the threads are stuck.
> Will do. Just to make sure I'm doing this correctly: > > 1. I've updated the systemd service file to export the GOTRACEBACK=crash var > 2. I've updated the...
Yup, that looks correct!
gdb being unable to attach makes this sound like an OS bug, Go shouldn't do anything that prevents attaching. You could try using the perf tool to collect a system-wide...
Interesting, it seems to be spinning on some atomics. Could you expand the `runtime/internal/atomic.Cas` and `runtime/internal/atomic.goLoad64` nodes to see what is calling them?
> If that's not what you need, please let me know and I'll try again. Specific instructions would be great! Yeah, it doesn't look quite right. The perf UI is...
> I can also upload the perf.data file if that would help. Unfortunately the perf.data file doesn't include the symbol information (perf report finds the right binaries and reads them),...
> The theory from a friend who's much better versed in the internals of Linux: That is certainly possible. It is also possible that there is a bug in our...
The crashes are in the compiler and linker. Just double checking, do we build the toolchain with the race detector enabled on race builders, or just the tests?
https://perf.golang.org/dashboard/?benchmark=AppendMsgReplicateDecision-8&days=90&end=2022-10-26T19%3A24