Possible EOFException in SerializedPersistence during recompile
malonnnn opened this issue ยท 2 comments
I have a custom /warp command that reads the "warps file" (yaml). I've used it for literally years (2015ish) and today it randomly threw an EOFException when trying to read the file, but the file is intact.
Could not reproduce, subsequent commands, even identical, worked fine. My guess is a race condition that's going to be nigh impossible to solve. Maybe I shouldn't even bother reporting if it's not reproducible?
[16:37:01 INFO]: Supermalon issued server command: /warp skycade
[16:37:02 WARN]: java.io.EOFException
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2926)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream$BlockDataInputStream.readUnsignedShort(ObjectInputStream.java:3433)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:3491)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readString(ObjectInputStream.java:2104)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1726)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:514)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:472)
[16:37:02 WARN]: at java.base/java.util.HashMap.readObject(HashMap.java:1550)
[16:37:02 WARN]: at java.base/jdk.internal.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
[16:37:02 WARN]: at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[16:37:02 WARN]: at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[16:37:02 WARN]: at java.base/java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1231)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2434)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2268)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1744)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:514)
[16:37:02 WARN]: at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:472)
[16:37:02 WARN]: at commandhelper-3.3.5-SNAPSHOT-full-build-293.jar//com.laytonsmith.persistence.SerializedPersistence$1.call(SerializedPersistence.java:10
6)
[16:37:02 WARN]: at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[16:37:02 WARN]: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
[16:37:02 WARN]: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
[16:37:02 WARN]: at java.base/java.lang.Thread.run(Thread.java:833) ```
Looks almost identical to my #1279. This is happening in ser data sources, not yml. Specifically it's getting to a key in the database file, expecting 2 bytes for the length of the following string, but reaching the end of the stream. I'm fairly certain this will only happen if something is actively writing to the file when the database is loaded again. I can replicate it by recompiling during long writes (which is what appears to have happened in my stacktrace). You don't seem to be getting this after a recompile, so it's less clear how this happened in your case.