Describe the Bug

Create has been found to leak on Quilt with both Quilted and Fabric API Indigo. Further testing is needed to determine if it is an upstream issue with the Forge version of Create. After further testing, this report is not applicable to be forwarded upstream. The only part of Create on Forge that retains memory is Flywheel, which seems to be temporary at most, as it hasn't caused any extreme memory usage on its own.

Reproduction Steps

1. Set the render distance sufficiently high to show the memory leak quickly. 8-16 chunks shows this pretty quickly.
2. Set the memory limit low to show the effects of the memory leak quickly.
   • -Xmx1G was chosen with Lithium, LazyDFU and FerriteCore installed.
   • You may want 2-4G without LazyDFU and FerriteCore.
3. Load any world.
   • A Create contraption does not need to be present.
   • A server is applicable.
   • A server not running Create may also work for this case.
4. Switch dimensions or worlds several times or until the garbage collector starts killing frame time.
5. Optional: Heap dump the client at this time using JDK Mission Control (I would highly recommend for quick transversal of the object tree, as this will be highly duplicated by nature), VisualVM, jcmd, or Spark, if installed.

• You may alternatively use a heap dump on out of memory flag and continue doing above until the game crashes.

Expected Result

For the client to continue running normally without any (notable) leak from Create or any other mod present.

Screenshots and Videos

No response

Crash Report or Log

N/A - This doesn't cause a crash unless you continue.

Operating System

Arch Linux + Kernel 5.19.11-arch1-1 + Mesa 22.2.1

Mod Version

0.5.0g

Minecraft Version

1.19.2

Other Mods

• Quilt Loader 0.18.1-beta.18
• AppliedEnergistics2 Fabric 12.8.5
• BetterRecipes 1.3.0
• Botania 1.19.2-436-FABRIC (Commit de969aab76868a60e5d1ae4b62d1f377ec740f03)
• Ears 1.19-1.4.6
• Fabric API 0.67.1+1.19.2 OR QFAPI-4.0.0-beta.21+QSL-3.0.0-beta.21+FAPI-0.67.0+MC-1.19.2
• FastBench 1.19.2-3 (PR Tfarcenim/FabricFastBench#22)
• FerriteCore 5.0.0
• Gadget 0.1.3
• LazyDFU 0.1.3
• Lithium 1.19.2-0.10.2
• owo-lib 0.8.3+1.19
• Patchouli 1.19.2-77-FABRIC
• Tom's Storage 1.19-1.4.3
• Trinkets 3.4.1
• YetAnotherConfigLib 1.7.1

Additional Context

• Logistics (Found via VisualVM)
  

• Flywheel (Found via VisualVM)
  

• com.simibubi.create.foundation.utility.WorldAttached.attached (Found via JMC)
  
  
  

• com.simibubi.create.content.logistics.trains.track.TrackBlockOutline:TRACKS_WITH_TURNS
  

Reproduced issue with b7a90f3 in dev.
Annoyingly, VisualVM's compare heap dumps feature doesn't actually work for this.

It looks like WorldAttached is not getting a clear call for the ClientLevel, examining the invalidateWorld call with a debugger, and only counting 3 ServerLevels passing through it

A defence of using a WeakHashMap at WorldAttached.attached can help avoid memory leaks by missed calls, but this is only a band-aid around the root problem: invalidateWorld not getting the ClientLevel call on Fabric.

This does not appear to be an issue upstream with Forge 43.1.7 + Flywheel 0.6.7-8 + Create 0.5.0.f. This report is not applicable to be forwarded upstream.

Out of curiosity: Memory leak is still present with just:

• Quilt Loader 0.18.1-beta.18
• Fabric API 0.67.1
• Create 0.5.0g
• LazyDFU 0.1.3

Which practically kills it nearly immediately on -Xmx1G

Update: 269M is retained after setting -Xmx2G and going between the nether and overworld several times with the above mod set minus LazyDFU.

9fbb71e seems like the commit that has fixed it upstream. Will check for its presence here. It is present, but it's still leaking? Is there some other relations that's causing leaking that just isn't present in a Forge environment?