[1.16.1] Client crash when unloading chunks containing IE wires
Glitchster00 opened this issue ยท 16 comments
Description of the issue:
When the player moves too far from a chunk with IE wires in it and the chunk unloads, the client crashes
Crashlog:
Versions & Modlist
Could this crash be related? https://pastebin.com/b6PyNY8J
could be, the stack trace looks different on the crash log I sent
I have had the crash a few times since on unloading or sometimes loading the chunk
Unloading
https://pastebin.com/u3JyjCnE
Loading
https://pastebin.com/X8YLRKpR
not sure if the loading chunk error is related but I put it here because it also points to IE wires as the culprit
I have been unable to reproduce the unloading crash. The loading crash makes sense and I can probably fix it, but I have no idea how the unloading crash is supposed to happen. Some connector either unloads before being "fully loaded" or unloads twice for whatever reason.
Is this crash reproducible for you (i.e. does it happen every time you try to unload some specific area)? If it is, it would be great if you could enable enableWireLogger
in the IE config, trigger the crash and send me the resulting log. It will produce some log spam, but it should be within reason (as long as you do not turn on validateNets
).
I turned on wirelogger and reproduced the crash, but where do I find the log? Is it just in the regular crash-reports/crash....txt file?
The bug is happening on a server that I run, it has happened multiple times to different people on the server but all when loading/unloading specific chunks containing ie wires.
I will enable wirelogger and get back to you with a log
The second crash is unrelated and should go into a new issue.
That log stops after you reach the main menu. Is that debug.log
or latest.log
? debug.log
would be the one I need. It may turn out to be too large for pastebin (I don't remember what their limit is, it's fairly low IIRC), https://gist.github.com should be able to handle it without issues.
One of my players was able to recreate the bug after I had them enable Wirelogger
Crash report:
https://pastebin.com/nEWHKT9F
Log:
https://pastebin.com/Bw0ktcdH
They also encountered this crash when trying to re create it, the crash report indicates it's also a rendering error so I thought it might be related, but I can make a new post if not
Crash report:
https://pastebin.com/0vBVMjSL
Update:
was able to confirm that Optifine is not responsible for the crash, I have replicated the issue multiple times without Optifine installed. The crash seems to occur when a player is loading/unloading the chunk many times and will not usually occur if the player only loads the chunk once or twice. One of my players who lives far away was able to visit the chunk with no issues by teleporting in and out of the area, but other players have tried this and crashed
github gist is not cooperating for some reason, so I have tried to copy only the part of the log that was leading up to the crash to avoid the limit on pastebin
Log:
https://pastebin.com/Eti43na6
Crash report:
https://pastebin.com/iTXcbg9Y
i am bit confused, as i do have not fully understood what
Preconditions.checkArgument(!(iicPos instanceof IICProxy));
shall accomplish but in my understanding it SHOULD generate this exception when the condition is not met, but it is never catched and handled properly or am is missing something here?
i'd plainly suggest to extend that check and add a debug message to it
Preconditions.checkArgument(!(iicPos instanceof IICProxy), String.format("Check failed for %s", iicPos));
to be more precise, the "null" from the illegalArgument is just a missing "else" message for the checker but as i just recognize the "!" in front of the check the reuslt should be clear, it fails whenever iicPos is NOT an IICProxy, so it is either itself null or something completely different but we can not know unless we print it out
but it is never catched and handled properly or am is missing something here?
The exception is intentionally never caught anywhere. If a connector unloads it should not be a proxy (i.e. an unloaded connector), so something has gone horribly wrong. And I'd rather crash at the first point where I see anything wrong than crash 6 hours later when the whole network is messed up.
i'd plainly suggest to extend that check and add a debug message to it
Yes, I'm working (once again) on cleaning up the wire network code, a) to make it unit testable and b) to add proper error messages to everything.
And I'd rather crash at the first point where I see anything wrong than crash 6 hours later
that is why i suggested to add an human readable error message to all those chechkArguments :)
I have indeed encountered this same crash (and posted my own issue report for it - I didn't see this one when I checked. Oops). One workaround for it is to use the /forceload command on all chunks that contain wires, this will prevent it from unloading
I have also encountered this problem in my world.
Here is a crash report and log with wireLogger enabled.