3 ms·
> I agree, the author has probably not worked on hard problems. Conversely, if you focus on creating a repro you make problems easy. I’m a little surprised th
by forrestthewoods 2y ago
> I agree, the author has probably not worked on hard problems.
Conversely, if you focus on creating a repro you make problems easy.
I’m a little surprised the OP doesn’t mention debuggers. For whatever reason many modern Linux programmers seem to have never and used a debugger and rely almost entirely on printf. Which is utterly bonkers to me! If you can repro and issue and trap it in a debugger then you’ve done 90% of the work.
- glandium 2y agoAnd if you can repro in rr, you've done 99% of the work most of the time.
- vardump 2y agoDebuggers are not great when you have a bug that occurs between multiple CPU cores, hardware device timing, etc. In those cases, a debugger just can't stop the world, so back to printf it is.
- forrestthewoods 2y agoprintf also mucks with sensitive timing issues. So it’s not great either. Also time traveling debuggers like WinDbg and rr are the ideal way to debug complex timing issues.
- vardump 2y ago> printf also mucks with sensitive timing issues. So it’s not great either. True, but this can be worked around for example with lock free ring buffers etc. > Also time traveling debuggers like WinDbg and rr are the ideal way to debug complex timing issues. When applicable rr can be great indeed. Not sure how to apply TTD tools for example in kernel context. Nice to see Microsoft continues improving WinDbg. (Shame Visual Studio's debugger is so weak in comparison.)
- Neikius 2y agoWell I am aware there are ring 0 debuggers out there. Also running in a VM could help. Question is is there anything useful around you could just grab (for linux)? It should be possible at last.