Minecraftforge: Dedicated server does not crash when classloading client classes

[SilentChaos512]

Minecraft Version: 1.14.4

Forge Version: 28.0.105

Logs: https://gist.github.com/SilentChaos512/e8f0585072a47ba57190130bc0dc8bcd

Example Mod: https://gist.github.com/SilentChaos512/8e33780118d134c1ad58d41587b77752

Steps to Reproduce:

1. Use @Mod.EventBusSubscriber on a class that references a @OnlyIn(Dist.CLIENT) class
2. Watch the game generate a massive log file, then crash and burn much later in a random spot

Description of issue:

Dedicated servers do not crash when a mod classloads a client-only class. The game continues to run, but many events do not fire (notably registry events). The game will usually continue until some mod tries to access something like an item or capability, which was never initialized. This means any mod could appear to be the cause of the crash in the crash report.

Included above is a simple example mod. It classloads GuiScreenEvent and prevents all registry events from firing. It later crashes the game in FMLServerStartingEvent by reference a block that was never initialized. Again, the place where the game ultimately crashes could be in any mod's code, not just the one that caused the error.

[illyohs]

So I ran the test mod and that the error is logged in both the latest.log and debug.log

[MajorTuvok]

In some situations this causes another very misleading crash: the NewRegistry isn't fired and any ObjectHolders for these not created registry will error, whilst the originial class loading issue is quite often not logged.

[cpw]

This should not be the erroring behaviour. The mod load cycle does stop, yes, and it should not launch into the server. It should crash out before it gets there. I think something might be trying to load the server world during the crash. I don't know why yet.

[cpw]

OK. I can't reproduce the "it loads anyway" behaviour. It tries to start the server because of a bit of logic in the stoppingserver behaviour. I've made a correction so the server doesn't do that anymore.

[cpw]

Changes here. I'm considering this closed because this is a poor report.

71a482880957abd5fad800bc70e87f60b97049b3

[SilentChaos512]

Doesn't seem to be fixed in 28.1.6. Is there some reason the game can't just crash as soon as an error occurs? The results are unpredictable, but this usually creates very misleading crash reports. Most users don't check log files.

• The example mod still crashes on line 39 without any changes, which is way after event bus subscribers, where I would expect the crash.
• If you remove BadClass from the example mod it loads correctly.
• If you remove onServerStarting instead, the game doesn't crash at all! You can even start a client and connect to the server, but no recipes get loaded and no mod blocks/items are registered.

Consider that BadClass could be a part of another mod. The example mod could still be the one that crashes. Whichever mod happens to try accessing an object that failed to initialize first. The exact place the game crashes varies from machine to machine, or even run to run, on the same mod pack.

[cpw]

@silentchaos512 post a fucking log file. This is not how it behaves in my testing AT ALL. Currently I think you have something else seriously fucked up in your environment and I will not make any further changes or reopen this issue without a COMPLETE debug level log file with ALL markers enabled.

[SilentChaos512]

• Run server with example mod (no changes, crashes in onServerStarting): https://gist.github.com/SilentChaos512/218f244f54600eda7f27e7a1e80bebb2
• Run server with example mod (BadClass removed, loads correctly): https://gist.github.com/SilentChaos512/b3e0e89db8b0d75356d517f0d92b67a6
• Run server with example mod (onServerStarting removed, does not crash but should): https://gist.github.com/SilentChaos512/df615bb1500d87537cc94af99c96af25

[cpw]

Yeah, you need a big pack to actually produce a significant issue here. Local testing would never show the _real_ problem up. Note your logs are not useful - they are truncated about 1/3 of the way through. I noticed this independently.