fast-serialization: Random Deserialization Problem with fst 2.57

We are using fast-serialization now for over a year in our application and it worked like a charm. But with the last version deployed this week, we switched from version 2.47 to 2.57. Everything worked fine in our QA enviroment. But in Production things got weird.

Basically we use the library to serialize and deserialize sessions to and from a Relational DB. In PROD the deserializing produces strange results in some cases. Mostly a java.lang.String.equals call failed inside the string class at line 982 int n = value.length;. The internal value field of the String was null. This should never happen. Except when you mess up the String with reflection. But we were pretty sure we don’t do this 😉 It went that far, that the jvm terminated with a Sementation Error when such maleformed data was accessed.

I wrote a small programm that checked every session in the database. And there where indeed some sessions that failed. I removed them and let the program run again. But wait…now other sessions, that where valid in the first run, failed in the second run. But the binary data was exactly the same 😲

Now we had the idea to try it with the older version 2.47 we used before. And what should I say. The same sessions, written with version 2.57, could be read with version 2.47 without any problem. So the problem must lay in the deserialization logic of fst 2.57.

I tracked it down now to a set of 3 Session objects. When they are deserialized in a specific order, the deserialization does pretty weird stuff for the last sesison object. Most noticalbe it sets a field of type “String” to a List of other Objects.

Some things to note

• Happens on Windows 10 and Linux systems
• Reproducable on oralce jdk 1.8_181-x64 and

openjdk version "1.8.0-adoptopenjdk"
OpenJDK Runtime Environment (build 1.8.0-adoptopenjdk-_2018_05_19_00_59-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

• We use fst on a server and use a ThreadLocal like suggested by the docs private static final ThreadLocal<DefaultCoder> CODERS = ThreadLocal.withInitial(() -> new DefaultCoder()); But my test Testcase shows that it also happens in a simply main class without any threads and also with FSTOBjectInput Instances obtained by the FSTConfiguration. As long as you reuse a Instance it might happen from time to time.

TestCase

~I have a TestCase ready. But I have to make sure first, that I’m allowed to upload it to github as it contains code written for our project at work. I will update this issue as soon as I have uploaded the test case.~ The test case including a description is available at https://github.com/furti/fst-deserialization-problem

But maybe someone has the same Problem or has an idea what could be the cause for this strange behaviour? I’m pretty sure it must be something in the library. But it could also be something we do wrong. So excuse me if that is the case 😃