问题
With unknown reason, boost binary serialization doesn't work occasionally. The parsed data is corrupted sometimes.
Originally I serialized instances of self-defined class manually, with each instance being a line in a text file. However, the speed was slow.(The text file was dealt in a speed of 2 MB/sec, which can be seen in windows task manager.) Recently I changed to use the boost binary serialization. However, strange things happens.
I stored many many instances of class InstanceIdentity, which contains a string member variable and a struc member variable representing the x-y-z integer coordinates.
My Problem: The previous 504 instances can be parsed from the binary file successfully and printed to screen. However the 505th instance is falsely parsed.(The x-y-z coordinates should be no more than 512.) And then the following instances become a mess. And soon an unknown exception is thrown from boost. I tried to catch it and used the .what() method to reveal more information. However, it only says Unknown Exception
.
line 503: 029_4_.s_raw.gz (306, 215, 64)
line 504: 029_4_.s_raw.gz (224, 154, 86)
line 505: 029_4_.s_raw.gz (68109, 36608, 16384)
// Then the screen output becomes a mess. I can't even copy the mess here.
My trials to solve it.
I checked this page http://boost-users.boost.narkive.com/70Yjldp7/boost-serialization-throws-random-exceptions . And I made sure the ifstream and ofstream is opened as binary:
out_file_stream.open(file_name, ios_base::out | ios_base::binary);
in_file_stream.open(file_name, ios_base::in | ios_base::binary);
But the problem continues.
- I tried to serialize the same data in text file using boost. (Only the file open mode and boost archive type need to be changed.)
The data can be serialized and deserialized successfully through text file. Since this probably implies the correctness of the serialize function in my self-defined class InstanceIdentity, the problem of boost binary serialization gets weirder.
I opened the boost binary file in hex editor (notepad++ plugin) and tried to find something at the 505th instances. The hex of the xyz coordinates of 504th instance is:
// 1st instance x-y-z
169=0xA9 144=0x90 79=0x4F
// And I can find 00 00 00 a9 00 00 00 90 00 00 00 4f in the appropriate location.
// 502th instance x-y-z
137=0x89 268=0x10C 136=0x88
// But I can't find 00 00 00 89 00 00 01 0c 00 00 00 88 in the whole binary file, even if this instance is correctly parsed by boost.
// 503th instance x-y-z
306=0x132 215=0xD7 64=0x40
// But I can't find 00 00 01 32 00 00 00 d7 00 00 00 40 in the whole binary file, even if this instance is correctly parsed by boost.
// 504th instance x-y-z
224=0xE0 154=0x9A 86=0x56
00 00 00 e0 00 00 00 9a 00 00 00 56
// But I can't find 00 00 00 e0 00 00 00 9a 00 00 00 56 in the whole binary file, even if this instance is correctly parsed by boost.
Questions: Does anybody know what's happening inside the boost binary file? What should I do to serialize my instances to binary file and deserialize them from it? I am using the same computer, so I think this problem is not about portability.
Environment: Windows 8 64 bit, visual studio 2013, boost 1_59_0 version.
回答1:
I am very very sorry for posting this question. The boost binary serialization works as expected. I just made a minor mistake but didn't find it until few minutes ago.
I am probably the stupidest programmer in the world. In my function, I uses a bool parameter identity_file_in_binary
to let the user choose whether a binary file is preferred. Then I uses a if-else
clause to run .open()
in different mode. I should have been using iso_base::binary
in the if
scope but mistakenly put it in the else
scope. After I corrected this mistake, my program worked smoothly.
PS: I have spent 2 days on finding the source of my problem, during which I have checked the erroneous if-else
clause many many times but overlooked the mistake. How could this thing happen? Does anyone have some good ideas to prevent this type of mistakes?
来源:https://stackoverflow.com/questions/32804174/boost-binary-serialization-doesnt-work-occasionally-the-parsed-data-is-corrupt