I think this change would reduce the probability of a race, but not completely eliminate it.

In the current version of the code, the goroutine that generates the log message is readingcoderd.options.Logger, then callingDebug() on it which eventually callst.Log(). MakingLogger an atomic reference and clearing it during cleanup doesn't fix this, because a concurrently running goroutine might read the value ofLogger before it's cleared, but then callt.Log() after the test exits.

Here's a minimal example that demonstrates the same issue. It succeeds on the playground, but fails if run with-race -count=100.

I think fixing this properly requires pushing the synchronization all the way toslogtest.testSink. Something like:

type testSink struct {    tb testing.TB    mutex sync.Mutex    testDone bool}

I looked into doing something like that as my first option, but how would the test sink know when the test exits?

Hmm, I guess maybe if the sink had its ownt.Cleanup that set the flag that would work?

Yeah, at first I was thinking we'd have to makeslogtest.Make return an extra function/object/something to provide a way for the test code to signal that it was done, but just having the sink register its own cleanup function is much more elegant.

Closing in favor ofcoder/slog#146 and#1759