Immersive Engineering

Immersive Engineering

134M Downloads

[1.16.1] Client crash when unloading chunks containing IE wires

Glitchster00 opened this issue ยท 16 comments

commented

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:

https://pastebin.com/TLJJWM2i

Versions & Modlist

https://pastebin.com/xbAk1GdJ

commented

Could this crash be related? https://pastebin.com/b6PyNY8J

commented

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

commented

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).

commented

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?

commented

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

commented

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.

commented

Try the folder called "Logs"

commented

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

commented

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

commented

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

commented

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.

commented

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 :)

commented

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

commented

I have also encountered this problem in my world.
Here is a crash report and log with wireLogger enabled.

commented

it is being worked on right now :)

commented

Malte if you are still unable to reproduce the crash, ping me in discord, i have a sevrer up where im able to reproduce it fairly often, and it happens to more than just myself. (running latest CF 1.16 build + forge ...75)