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 more
This 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
invoke
instead ofinvokeExact
Using regular reflection instead of
MethodHandle
(this code doesn't need to be high-performance)
Attachments
Comments 0
No comments.