Data race in WithName() implementation? about zapr

[pohly]

Kubernetes 1.19.0? That didn't use go-logr/zapr yet.

Ah, zap v1.19.0.

[pohly]

zapr/zapr.go

Line 228 in df10f47

newLogger.l = zl.l.Named(name)

That's the same line in zapr for the read and write, and the actual write occurs in zap. Can you file a bug in zap for this? This looks like something internal to zap.

[pachanga]

Oh, my bad I meant "I'm using v1.2.3 with zap v1.19.0" :) I'll try to manually re-pin zapr to the newer version of zap and see how it goes.

[pachanga]

After some investigation I think I've figured out why this data race happened and I'm not sure if this is an issue. Here's a simplified pseudo code which triggered a data race:

func newPool(logger logr.Logger) *Pool {
   return &Pool {
        IdleAmount: 16, //<--- spawns 16 goroutines using Dial attribute below
        Dial: func() (Conn, error) {
           logger = logger.WithName("[pool]") //<--- data race error is here
           ...
           return &Conn{logger}
        }
   }
}

It seems the data race happened because newPool's function argument logger was changed by multiple goroutines. Once I rewrote the code as follows the problem was gone:

func newPool(logger logr.Logger) *Pool {
   return &Pool {
        IdleAmount: 16, //<--- spawns 16 goroutines using Dial attribute below
        Dial: func() (Conn, error) {
           newLogger = logger.WithName("[pool]") 
           ...
           return &Conn{newLogger}
        }
   }
}

[pohly]

And this Dial callback gets invoked by multiple different goroutines concurrently, right? Yes, that leads to read/write race because one goroutine reads from it while another writes to it.

It's also semantically incorrect: logger = logger.WithName("[pool]") adds "[pool]" to the logger over and over again, making the name longer with each invocation.

[pachanga]

And this Dial callback gets invoked by multiple different goroutines concurrently, right? Yes, that leads to read/write race because one goroutine reads from it while another writes to it.

It's also semantically incorrect: logger = logger.WithName("[pool]") adds "[pool]" to the logger over and over again, making the name longer with each invocation.

Yep, that's right. That was a bug. I guess we can close the issue?