Memory leak during failed xml deserialization #260
Comments
|
I've taken a brief look at this in case it was something simple. It's not. At least I couldn't figure it out in the short time I looked at it. I can offer some hints though.
Sorry this isn't the answer you're looking for. But I don't know what else to suggest. Look the bright side. You keep the test_apps (under different names of course). So that every time a changes is made anywhere or different environment (compiler, etc) is selected (and only when that happens) , you'll automatically detect any problems when they occur. In other words, the above is a one time investment, but it pays dividends for ever. Robert Ramey |
|
I tried the following cases: |
|
Thanks for doing this. "Archive.delete_created_pointers() only works for derivedObj*" looks to me that what we really want to say is: Archive.delete_created_pointers() only FAILS for derivedObj* ? FYI - the fact that this is an xml_archive shouldn't have anything to with this. BUT it could and it would be interesting to know if did. It might be interesting to run this with a text archive rather than an xml one (which inserts another layer of objects into the tree). I'm also curious what the phrase "Leak after ..." means. The leak is only produced/detected when the interrupt is caught right? I'm guessing the perhaps this means that the place where the leaked object was created as shown in the backtrace? |
Well, for cases involving shared pointers, the allocated pointers are not passed to shared_ptr(use_count == 0). So I assume delete_created_pointers should free them, no?
I can try text archive.
Yes. the sample code is below. try {
ar & boost::serialization::make_nvp("anObject", base_sp); // derived_sp, base_ptr, derived_ptr
} catch(...) {
// std::cout << derived_sp.use_count();
// std::cout << base_sp.use_count();
// ar.delete_created_pointers();
// delete derived_ptr;
// delete base_ptr;
throw;
} |
|
Text archives have the same memory leak behavior. I think the walkaround is to use raw pointers. Make share if everything goes fine. Otherwise, we have to manually delete the pointers. |
|
taking a little more time with this. If you're serializing a vector of base class pointers it looks like things always work. If you're using an vector of base class pointers (shared or not), but serializing a derived pointers, I would not be surprised that there might be problems perhaps related to slicing somewhere. Still, using shared_ptr<Base*> and Base* should work the same. So I would next investigate a little deeper shared_ptr<Base *>. Note: it looks like you're compiling in release mode and thus linking the release level libraries which don't have debug code, line #, etc. It might be a good idea to see what happens while compiling/building/testing in debug mode. |
|
I used a simpler case to reproduce the leak. More information is provided by the debug version. |
I have a project using boost::serialization (version 1.74) to and from xmls. Recently, we removed a data member inside a serializable class. When we try to read the old xml (the removed field is still in xml), the deserialization failed as expected. However, when we run Valgrind through the failed deserialization, we found some memory leak. I searched the internet for solution, and tried to catch the exception and do 'delete_created_pointer()', etc. However, nothing worked. I really need your help. Following are some details.
From xml, we read a vector of objects, and store them in shared_ptr of the common base class (serialization is exactly opposite):
The Valgrind report is like below:
Thanks in advance.
The text was updated successfully, but these errors were encountered: