MixinConfigPlugin class corrupted, likely by another mod
Neubulae opened this issue ยท 13 comments
latest.log
This is the most concerning crash log I've ever acquired
looks like the mixin plugin had an error in a way that made mixin decide to dump the entire contents of the JVM stack in the log.
I've looked through the mod list and, of the things I recognize, don't see anything terribly suspect. The things I thought might cause problems (MixinTrace, NotEnoughCrashes) seem to work fine on their own. I don't know what eer or loadcatcher (EDIT: loadcatcher is the client-side portion of NotEnoughCrashes) are. I have good guesses for manyacharacter (NotEnoughCharacters fork?) and geyser-fabric (GeyserMC? The Bedrock<->Java translation layer?) but am not totally sure what they are.
The presence of simpleauth makes me wonder if this is caused by a pirate launcher fucking the game up. (I really could not give a shit if you are cheating Micro$oft out of $20, but pirate launchers are well-known for causing all sorts of trouble and breaking things real bad.)
The presence of simpleauth makes me wonder if this is caused by a pirate launcher fucking the game up. (I really could not give a shit if you are cheating Micro$oft out of $20, but pirate launchers are well-known for causing all sorts of trouble and breaking things real bad.)
Good assumption, yet this is a server-side crashlog.
Ah, I missed Mixin mentioning the environment. (This is an incredibly short log, a lot of the usual landmarks are totally missing.)
All I can recommend is removing mods one-by-one until you figure out which one is causing this. (Binary searching the mod list, if you know how to do it, is a lot faster, but I'm not quite sure of the best way to explain how to do it in sufficient detail.)
Once it's known why this is happening, I can look more into why and try and fix it.
More potentially useful background: Fabrication uses a somewhat obscure feature in Mixin that allows full code control over what mixins are loaded. I use it to make it so disabled features are never loaded at all to avoid incompatibilities being caused by disabled features.
The first part of doing this is the discovery process, where I scan my own classpath and figure out what mixins are available and under what conditions they can be enabled. This process uses ObjectWeb ASM to load my own classes and read their annotations without patching them at all. For some reason, in your copy of Minecraft, an essential part of the ASM API is missing, and ClassNode does not implement ClassVisitor like it is supposed to.
I've just tested Fabrication under 1.16.4 and it works, so this isn't related to the Minecraft version.
After using a real JDK11 the crash log became this:
net.fabricmc.loader.api.EntrypointException: Exception while loading entries for entrypoint 'main' provided by 'fabrication'
at net.fabricmc.loader.EntrypointStorage.getEntrypointContainers(EntrypointStorage.java:193) ~[fabric.jar:?]
at net.fabricmc.loader.FabricLoader.getEntrypointContainers(FabricLoader.java:272) ~[fabric.jar:?]
at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointUtils.invoke0(EntrypointUtils.java:44) ~[fabric.jar:?]
at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointUtils.invoke(EntrypointUtils.java:36) ~[fabric.jar:?]
at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointServer.start(EntrypointServer.java:32) ~[fabric.jar:?]
at net.minecraft.server.Main.main(Main.java:92) [intermediary-server.jar:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at net.fabricmc.loader.game.MinecraftGameProvider.launch(MinecraftGameProvider.java:224) [fabric.jar:?]
at net.fabricmc.loader.launch.knot.Knot.init(Knot.java:141) [fabric.jar:?]
at net.fabricmc.loader.launch.knot.KnotServer.main(KnotServer.java:27) [fabric.jar:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
at net.fabricmc.loader.launch.server.FabricServerLauncher.launch(FabricServerLauncher.java:62) [fabric.jar:?]
at net.fabricmc.loader.launch.server.FabricServerLauncher.setup(FabricServerLauncher.java:106) [fabric.jar:?]
at net.fabricmc.loader.launch.server.FabricServerLauncher.main(FabricServerLauncher.java:50) [fabric.jar:?]
Caused by: java.lang.NoSuchMethodError: 'sun.reflect.ConstructorAccessor sun.reflect.ReflectionFactory.newConstructorAccessor(java.lang.reflect.Constructor)'
at com.unascribed.fabrication.FabricationMod.<clinit>(FabricationMod.java:55) ~[fabrication-1.2.3.jar:?]
at java.lang.Class.forName0(Native Method) ~[?:?]
at java.lang.Class.forName(Unknown Source) ~[?:?]
at net.fabricmc.loader.util.DefaultLanguageAdapter.create(DefaultLanguageAdapter.java:45) ~[fabric.jar:?]
at net.fabricmc.loader.EntrypointStorage$NewEntry.create(EntrypointStorage.java:114) ~[fabric.jar:?]
at net.fabricmc.loader.EntrypointStorage$NewEntry.getOrCreate(EntrypointStorage.java:101) ~[fabric.jar:?]
at net.fabricmc.loader.EntrypointStorage.getEntrypointContainers(EntrypointStorage.java:186) ~[fabric.jar:?]
... 19 more
Is this still conflict?
"A real JDK 11"? What were you using before?
This crash is new, caused by a feature in 1.2.3 I neglected to test on a restrictive JRE. You're making it past the point that the other crash occurred, though.
"A real JDK 11"? What were you using before?
This crash is new, caused by a feature in 1.2.3 I neglected to test on a restrictive JRE. You're making it past the point that the other crash occurred, though.
It was a JDK 8, didn't pay much attention
JDK 8 should work... whatever, as long as it works now.
Tested, it works now on Java 11