I get the following error while reading from boost::archive::binary_iarchive into my variable:
test-serialization(9285,0x11c62fdc0) malloc: can't allocate region
*** mach_vm_map(size=18014398509486080) failed (error code=3)
test-serialization(9285,0x11c62fdc0) malloc: *** set a breakpoint in malloc_error_break to debug
My serialization and deserialization code are:
template<class Archive>
void save(Archive & archive, const helib::PubKey & pubkey, const unsigned int version){
BOOST_TEST_MESSAGE("inside save_construct_data");
archive << &(pubkey.context);
archive << pubkey.skBounds;
archive << pubkey.keySwitching;
archive << pubkey.keySwitchMap;
archive << pubkey.KS_strategy;
archive << pubkey.recryptKeyID;
}
template<class Archive>
void load_construct_data(Archive & archive, helib::PubKey * pubkey, const unsigned int version){
helib::Context * context = new helib::Context(2,3,1); //random numbers since there is no default constructor
BOOST_TEST_MESSAGE("deserializing context");
archive >> context;
std::vector<double> skBounds;
std::vector<helib::KeySwitch> keySwitching;
std::vector<std::vector<long>> keySwitchMap;
NTL::Vec<long> KS_strategy;
long recryptKeyID;
BOOST_TEST_MESSAGE("deserializing skbounds");
archive >> skBounds;
BOOST_TEST_MESSAGE("deserializing keyswitching");
archive >> keySwitching;
BOOST_TEST_MESSAGE("deserializing keyswitchmap");
archive >> keySwitchMap;
BOOST_TEST_MESSAGE("deserializing KS_strategy");
archive >> KS_strategy;
BOOST_TEST_MESSAGE("deserializing recryptKeyID");
archive >> recryptKeyID;
BOOST_TEST_MESSAGE("new pubkey");
::new(pubkey)helib::PubKey(*context);
//TODO: complete
}
template<class Archive>
void serialize(Archive & archive, helib::PubKey & pubkey, const unsigned int version){
split_free(archive, pubkey, version);
}
template<class Archive>
void load(Archive & archive, helib::PubKey & pubkey, const unsigned int version){
}
The test that calls the code is the following:
BOOST_AUTO_TEST_CASE(serialization_pubkey)
{
auto context = helibTestContext();
helib::SecKey secret_key(context);
secret_key.GenSecKey();
// Compute key-switching matrices that we need
helib::addSome1DMatrices(secret_key);
// Set the secret key (upcast: SecKey is a subclass of PubKey)
const helib::PubKey& original_pubkey = secret_key;
std::string filename = "pubkey.serialized";
std::ofstream os(filename, std::ios::binary);
{
boost::archive::binary_oarchive oarchive(os);
oarchive << original_pubkey;
}
helib::PubKey * restored_pubkey = new helib::PubKey(helib::Context(2,3,1));
{
std::ifstream ifs(filename, std::ios::binary);
boost::archive::binary_iarchive iarchive(ifs);
BOOST_TEST_CHECKPOINT("calling deserialization");
iarchive >> restored_pubkey;
BOOST_TEST_CHECKPOINT("done with deserialization");
//tests ommitted
}
}
Considerations:
Serialization works both fine with
boost::archive::text_oarchiveandboost::archive::binary_oarchive. They create a file of 46M and 21M respectively (big, I know).Deserialization with
boost::archive::text_iarchivebasically stopped at the execution ofarchive >> keySwitching;The process gets automatically killed. This is in fact the biggest part of the archive.I decided to try with
boost::archive::binary_iarchivesince the file is half the size, but I get the error shown at the beginning. The error happens while executing the first read from the archive:archive >> context;.The asymmetry between input and output (
saveandload_construct_data) is because I could not find another way to avoid the implementation of the serialization of a derived class ofhelib::PubKey. Using a pointer tohelib::PubKeywas giving me compilation errors asking for the serialization of the derived class. If there is some other way I'm all ears.
Thank you for your help.
UPDATE:
I am implementing deserialization for some classes in the cryptographic library HElib because I need to send ciphertext over the wire. One of these classes is helib::PubKey. I'm using the boost serialization library for the implementation. I have created a gist to provide a reprex as suggested in the comments. There are 3 files:
- serialization.hpp, it contains the serialiation implementation. Unfortunately,
helib::PubKeydepends on many other classes making the file rather long. All the other classes have unit tests that pass. Furthermore, I had to make a tiny modification to the class with the goal of serializing it. I made public the private members. - test-serialization.cpp, it contains the unit test.
- Makefile. Running make creates the executable test-serialization.
vector<bool>strikes againIt's actually allocating for 0x1fffffffff20000 bits (that's 144 petabits) on my test box. That's coming directly from IndexSet::resize().
Now I have serious questions about HElib using
std::vector<bool>here (it seems they would be far better served with something likeboost::icl::interval_set<>).Well. That was a wild goose chase (that IndexSet serialization can be much improved). However, the real problem is that you had Undefined Behaviour because you don't deserialize the same type as you serialize.
You serialize a
PubKey, but attempt to deserialize asPubKey*. Uhoh.Now beyond that, there's quite a bit of problems:
You had to modify the library to make private members public. This can easily violate ODR (making the class layout incompatible).
You seem to treat the context as a "dynamic" resource, which will engage Object Tracking. This could be a viable approach. BUT. You'll have to think about ownership.
It seems like you didn't do that yet. For example, the line in
load_construct_dataforDoublCRTis a definite memory-leak:You never use it nor ever free it. In fact, you simply overwrite it with the deserialized instance, which may or may not be owned. Catch-22
Exactly the same happens in
load_construct_dataforPubKey.worse, in
save_construct_datayou completely gratuitously copy context objects for eachDoubleCRTin eachSecKey:Because you fake it out as pointer-serialization, again (obviously useless) object tracking kicks in, just meaning you serialize redundant
Contextcopies which will will be all be leaked un deserialization.I'd be tempted to assume the context instances in both would always be the same? Why not serialize the context(s) separately anyways?
In fact I went and analyzed the HElib source code to check these assumptions. It turns out I was correct. Nothing ever constructs a context outside
As you can see, they return owned pointers. You should have been using them. Perhaps even with the built-in serialization, that I practically stumble over here.
Time To Regroup
I'd use the serialization code from HElib (because, why reinvent the wheel and make a ton of bugs doing so?). If you insist on integration with Boost Serialization, you can have your cake and eat it:
That's all. 24 lines of code. And it's gonna be tested and maintained by the library authors. You can't beat that (clearly). I've modified the tests a bit so we don't abuse private details anymore.
Cleaning Up The Code
By separating out a helper to deal with the blob writing, we can implement different
helibtypes in a very similar way:This is elegance to me.
FULL LISTING
I have cloned a new gist https://gist.github.com/sehe/ba82a0329e4ec586363eb82d3f3b9326 that includes the following change-sets:
Only the last two commits contains changes related to the actual fixes.
I'll list the full code here too for posterity. There are a number of subtle reorganizations and ditto comments in the test code. You'd do well to read through them carefully to see whether you understand them and the implications suit your needs. I left comments describing why the test assertions are what they are to help.
File
serialization.hppFile
test-serialization.cppTEST OUTPUT
Bitwise Reproducible Outputs
On repeated serialization it appears that indeed the output is bitwise identical, which may be an important property:
Note that it is (obviously) not identical across runs (because it generates different key material).
Side Quest (The Wild Goose Chase)
One way to improve the IndexSet serialization code manually is to also use
vector<bool>:Better idea would be to use
dynamic_bitset(for which I happen to have contributed the serialization code (see How to serialize boost::dynamic_bitset?)):