Yeah, I was going to mention race conditions as soon as I saw the parent comment. Though I'd guess most cases where the debugger "fixes" the issue while print statements don't are also race conditions, just the race isn't tight enough that that extra IO time changes the result.

Best way to be thorough with concurrency testing IMO involves using synchronization to deliberately check the results of each potential race going either way. Of course, this is an exponential problem if you really want to be thorough (like some races could be based on thread 1 getting one specific instruction in between two specific instructions in thread 2, or maybe a race involves more than 2 threads, which would make it exponentially grow the exponential problem).

But a trick for print statement debugging race conditions is to keep your message short. Even better if you can just send a dword to some fast logger asynchronously (though be careful to not introduce more race conditions with this!).

This is one of the reasons why concurrency is hard even for those who understand it well.