Bug report: TrackingGet goroutine unsafe with onDelete func

[chenqiuhao1997]

When Running TrackingGet, func gc could insert like this:

// Used when the cache was created with the Track() configuration option.
// Avoid otherwise
func (c *Cache) TrackingGet(key string) TrackedItem {
	item := c.Get(key)
	if item == nil {
		return NilTracked
	}

// switch to gc goroutine
...
		if c.tracking == false || atomic.LoadInt32(&item.refCount) == 0 {
			c.bucket(item.key).delete(item.key)
			c.size -= item.size
			c.list.Remove(element)
			if c.onDelete != nil {
				c.onDelete(item)
			}
			dropped += 1
			item.promotions = -2
		}
...
// switch back

	item.track()
	return item
}

That would cause getting items which have been processed onDelete func.

[karlseguin]

I'm not sure I understand the problem. TrackingGet and onDelete will get the same item, but tonDelete could be called at any point that 1 (or many) copies of item are out in user-code.

Sure, the refcount of item will be brought back up to 1, but I don't see that as being 'unsafe'.

Maybe I'm misunderstanding?

[temka-io]

There is a race window where gc() can observe refCount == 0 for an item that TrackingGet is in the middle of returning. The item object itself survives, but if onDelete releases or recycles resources stored in item.value, the caller of TrackingGet may receive an item whose value has already been reclaimed.

Example: I put []byte buffers obtained from sync.Pool into the cache and, in onDelete, I return those buffers to the pool. If gc runs in the small window inside TrackingGet (between c.Get() and item.track()), onDelete will return the buffer to the pool. When TrackingGet resumes and returns the item, that []byte may already be reused for unrelated data, leading to incorrect behavior.

So the issue isn’t that the refcount is unsafe by itself; it’s that onDelete can run between Get() and track(). The item reference is still valid, but its underlying resources have been taken away by onDelete.

At the very least, I’d suggest documenting that, in very rare cases, onDelete may be invoked for items being retrieved via TrackingGet (i.e., while TrackingGet is in flight). I understand a fix might be non-trivial, so documenting this behavior would already be very helpful.