The game crashes when launching with the memory allocator debug mode enabled via -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugAllocator=true in the JVM arguments, with
java.lang.ExceptionInInitializerError
at cte.a(SourceFile:51)
at cte.<init>(SourceFile:42)
at ces.ak(SourceFile:431)
at ces.a(SourceFile:365)
at net.minecraft.client.main.Main.main(SourceFile:144)
Caused by: java.lang.RuntimeException: java.lang.invoke.WrongMethodTypeException: expected (long)long but found (long)void
at cek.a(SourceFile:41)
at cst.c(SourceFile:28)
at k.a(SourceFile:248)
at cst.<clinit>(SourceFile:28)
... 5 more
Caused by: java.lang.invoke.WrongMethodTypeException: expected (long)long but found (long)void
at java.lang.invoke.Invokers.newWrongMethodTypeException(Invokers.java:298)
at java.lang.invoke.Invokers.checkExactType(Invokers.java:309)
at cek.a(SourceFile:39)
... 8 moreThis started happening when the game switched to LWJGL 3.1.6 from 3.1.2 in 1.13-pre4, as a result of this change. 1.13-pre3 launches fine.
Code analysis
The affected code (which MCPConfig calls LWJGLMemoryUntracker) seems to be an ugly hack of some sort to manually mark allocations as ones that won't be explicitly freed since they last the entire time the game is running. It creates a MethodHandle that references DebugAllocator.untrack, and then stores that for later invocation if the DebugAllocator is in use. It uses invokeExact with that specific one, passing a single long parameter:
handle.invokeExact(pointer)However, this infers a void return type. Some different possibilities for fixing it:
Manually getting the return type, which requires
long size = (long)handle.invokeExact(pointer)(the cast is required).Using
invokeinstead ofinvokeExactUsing regular reflection instead of
MethodHandle(this code doesn't need to be high-performance)
Attachments
Comments 0
No comments.