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 of invokeExact
• Using regular reflection instead of MethodHandle (this code doesn't need to be high-performance)