search

LOOHP / ImageFrame

Put images on maps and walls!
https://www.spigotmc.org/resources/106031/
GNU General Public License v3.0
50 stars 14 forks source link

Possible memory leak #58

Closed w1th0utme closed 3 months ago

w1th0utme commented 5 months ago

Server version: 1.20.4 ImageFrame version: 1.7.8.2

Craft Scheduler Thread - 8607 - ImageFrame
  at com.loohp.imageframe.objectholders.AnimatedFakeMapManager.lambda$buildAllItemFrameInfo$0(Lorg/bukkit/entity/ItemFrame;Lcom/google/common/collect/ImmutableMap$Builder;Ljava/util/concurrent/CompletableFuture;)V (AnimatedFakeMapManager.java:122)
  at com.loohp.imageframe.objectholders.AnimatedFakeMapManager$$Lambda+0x00007f04f3fd4000.run()V ()
  at com.loohp.imageframe.objectholders.AnimatedFakeMapManager.buildAllItemFrameInfo(Ljava/util/Set;Z)Lcom/google/common/collect/ImmutableMap; (AnimatedFakeMapManager.java:130)
  at com.loohp.imageframe.objectholders.AnimatedFakeMapManager.run()V (AnimatedFakeMapManager.java:155)
  at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftTask.run()V (CraftTask.java:100)
  at org.bukkit.craftbukkit.v1_20_R3.scheduler.CraftAsyncTask.run()V (CraftAsyncTask.java:57)
  at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run()V (ServerSchedulerReportingWrapper.java:22)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1144)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:642)
  at java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V (Thread.java:1596)
  at java.lang.Thread.run()V (Thread.java:1583)

image

image

image

LOOHP commented 5 months ago

Which server implementation are you running?

w1th0utme commented 5 months ago

Which server implementation are you running?

I can say pufferfish. It's actually a UniverseSpigot, but it's based entirely on pufferfish and can't exactly break anything in that regard.

w1th0utme commented 5 months ago

Do you have any ideas about that?

ChanceSD commented 3 months ago

I found a similar thing using v1.7.9.0, this is from a heap dump with 0 players online so there should be 0 CraftPlayer instances image Seems like it comes from pendingKnownMapIds in com.loohp.imageframe.objectholders.AnimatedFakeMapManager, it's holding to Player instances even after they leave.

Dreeam-qwq commented 3 months ago

I found a similar thing using v1.7.9.0, this is from a heap dump with 0 players online so there should be 0 CraftPlayer instances image Seems like it comes from pendingKnownMapIds in com.loohp.imageframe.objectholders.AnimatedFakeMapManager, it's holding to Player instances even after they leave.

Under player quit event, remove player object from pendingKnownMapIds map maybe can solve this? https://github.com/LOOHP/ImageFrame/blob/e1fe6dc81ecf50c76562991400549844893b5013/common/src/main/java/com/loohp/imageframe/objectholders/AnimatedFakeMapManager.java#L338

btw, I think it's better to store player uuid as key instead of the entire player object.

ChanceSD commented 3 months ago

I found a similar thing using v1.7.9.0, this is from a heap dump with 0 players online so there should be 0 CraftPlayer instances image Seems like it comes from pendingKnownMapIds in com.loohp.imageframe.objectholders.AnimatedFakeMapManager, it's holding to Player instances even after they leave.

Under player quit event, remove player object from pendingKnownMapIds map maybe can solve this?

https://github.com/LOOHP/ImageFrame/blob/e1fe6dc81ecf50c76562991400549844893b5013/common/src/main/java/com/loohp/imageframe/objectholders/AnimatedFakeMapManager.java#L338

btw, I think it's better to store player uuid as key instead of the entire player object.

Yep, that's what I did on my fork, just removed it on quit event, not sure if there are any side effects but so far didn't notice any problem.