panic when adding element to cache using 3.4.0

[lucasoares]

I recently updated ttlcache to v3.4.0 and started seeing this type of error:

goroutine 417 [running]:
runtime/debug.Stack()
	/home/lucas/stilingue/go/src/runtime/debug/stack.go:26 +0x6b
github.com/gofiber/fiber/v2/middleware/recover.defaultStackTraceHandler(0xc000489208, {0x1dbc2c0, 0xc000157038})
	/home/lucas/go/pkg/mod/github.com/gofiber/fiber/v2@v2.52.8/middleware/recover/recover.go:12 +0x37
github.com/gofiber/fiber/v2/middleware/recover.New.func1.1()
	/home/lucas/go/pkg/mod/github.com/gofiber/fiber/v2@v2.52.8/middleware/recover/recover.go:31 +0x8b
panic({0x1dbc2c0?, 0xc000157038?})
	/home/lucas/stilingue/go/src/runtime/panic.go:792 +0x136
github.com/jellydator/ttlcache/v3.(*Cache[...]).updateExpirations(0x208dfe0, 0x0, 0xc00116aff0)
	/home/lucas/go/pkg/mod/github.com/jellydator/ttlcache/v3@v3.4.0/cache.go:106 +0x38c
github.com/jellydator/ttlcache/v3.(*Cache[...]).set(0x208dfe0, {0xc000dbe000, 0x836}, 0xc000dcae80, 0xdf8475800)
	/home/lucas/go/pkg/mod/github.com/jellydator/ttlcache/v3@v3.4.0/cache.go:156 +0x165
github.com/jellydator/ttlcache/v3.(*Cache[...]).Set(0x208dfe0, {0xc000dbe000, 0x836}, 0xc000dcae80, 0xdf8475800)
	/home/lucas/go/pkg/mod/github.com/jellydator/ttlcache/v3@v3.4.0/cache.go:363 +0x125

This might be related to #46.

I'm using a cache loader that can sometimes load the same element concurrently if two requests are performed at the same time for the same user.

My loader:

	loader := ttlcache.LoaderFunc[string, *model.MyModel](
		func(c *ttlcache.Cache[string, *model.MyModel], key string) *ttlcache.Item[string, *model.MyModel] {
			// .. do stuff

			item := c.Set(key, value, ttl)

			return item
		},
	)

[davseby]

What kind of panic do you receive?

Is it panic: runtime error: index out of range [0] with length 0 or panic: runtime error: invalid memory address or nil pointer dereference?

[lucasoares]

What kind of panic do you receive?

Is it panic: runtime error: index out of range [0] with length 0 or panic: runtime error: invalid memory address or nil pointer dereference?

I've seen the first one. Sorry, I accidentally cut that out from the logs. I rolled back to the previous version, so I'm not seeing this error anymore.

[swithek]

@lucasoares could you provide a simple example that triggers this panic or any other details that would help us reproduce this? This is to rule out the possibility that the panic was triggered by your own code in the .. do stuff section:

My loader:

loader := ttlcache.LoaderFunc[string, *model.MyModel](
	func(c *ttlcache.Cache[string, *model.MyModel], key string) *ttlcache.Item[string, *model.MyModel] {
		// .. do stuff

		item := c.Set(key, value, ttl)

		return item
	},
)

[lucasoares]

@lucasoares could you provide a simple example that triggers this panic or any other details that would help us reproduce this? This is to rule out the possibility that the panic was triggered by your own code in the .. do stuff section:

My loader:

loader := ttlcache.LoaderFunc[string, *model.MyModel](
	func(c *ttlcache.Cache[string, *model.MyModel], key string) *ttlcache.Item[string, *model.MyModel] {
		// .. do stuff

		item := c.Set(key, value, ttl)

		return item
	},
)

When I rolled back ttlcache, everything started working fine again.

I tried to debug it when I had some time, but I couldn't find any evidence that my "do stuff" code was panicking. Looking at the panic stack trace, it clearly originates inside ttlcache itself.

I also suspect that reproducing this issue requires multithreaded access to the loader and it's probably related to a race condition. I was using an older version of ttlcache (v3.0.1), so I couldn't pinpoint exactly which version this started happening. It seemed a bit random, to be honest, but happened a lot while I was using the newest ttlcache version.

I will try to find some time to debug it more again, but I checked all code that runs before the c.Set and I don't think it have a way to panic in there...

[swithek]

Yeah, this looks like one of those "edge case bugs." It would help a lot if you could debug this further or provide any additional information.

[arevno]

97% of panics in cache libraries like ttlcache are "caused" by zero-allocation or unsafe libraries upstream. If you're using something like gofiber, be aware that if you pass strings as keys without cloning them first, you may get wrecked, because the internal pointer either gets overwritten, moved, or deallocated.

Don't ask me how I know.

[swithek]

@arevno I've never used gofiber in any of my projects, so it's a bit hard to imagine the scenario you are describing (though it sounds interesting and a bit bizarre at the same time). Could you share an example of how these strings are produced and later used within the fiber lifecycle/handler? Thank you!