Leaking Bukkit player instances
AverageGithub opened this issue ยท 3 comments
Description
LuckPerms is leaking bukkit player instances.
I was trying to find a memory leak with Bukkit world unload (that doesn't actually exist, as it turns out), and after a heap dump analysis I found out that LuckPerms was keeping references to the player instances.
Reproduction Steps
Have LuckPerms on a server, leave and join the server a couple of times. Wait a minute, and wait until a GC has taken place, then take a heap dump, and see that there are more player instances than there should be.
Expected Behaviour
After looking at the implementation, the player instances should be removed from the cache after a minute after they've been written or when a player disconnects. (Currently, the players are only removed from the online players cache when they disconnect, a possible solution might be to invalidate that key in the other cache.)
Server Details
git-Paper-263 (MC: 1.20.2) (Implementing API version 1.20.2-R0.1-SNAPSHOT) (Git: 487109f)
LuckPerms Version
v5.4.106
Logs and Configs
No response
Extra Details
Heap dump: https://drive.google.com/file/d/1LpMByGvMr-45njzdErJfo9YcePp1rObB/view?usp=sharing (made on a test server, so doesn't contain any sensitive information)
There were 0 players on the server when the heap dump was recorded.
Hmm that's a fun one. I think the Caffeine cache only does housekeeping periodically, or during other operations on the cache. It should clear everything after approx 1 minute but might be a bit longer.
I haven't had any other reports of memory leaks, so maybe this is just a weird edge case?
Sorry - don't have the right tooling installed on my current machine to view your heap dump, but I will try to have a look soon when I'm back on my normal machine :)
The heap dump looks "correct" (there is a CraftPlayer pointed to by a (me.lucko.luckperms...)caffeine entry).
A Scheduler needs to be set for it to perform eager cleanup after the defined expiry times, otherwise it'll perform them lazily as the cache is accessed.
Realistically this is a very "small" and "short lived" leak as the cache is accessed, among other things, on player join so as soon as someone joins again it'll perform maintenance, but with just the right conditions it can keep many things loaded.
