Re: Re: Re:boost::serialization Remarks

Jeff,
Although, I am having problems with my VC71 MFC application reporting memory leaks of a 24byte block corresponding to each shared_ptr loaded from an oarchive.
You probably mean "loaded from an iarchive". Anyway, due to the modifications I've made in our local code base of boost::serialization I had a bit of a look through the code. I'm not sure, but the memory leaks you experience could possibly be related to the fact that basic_iarchive::delete_created_pointers is never called. Maybe you can add a call to this function yourself somewhere in your application (delete_created_pointers is a public member function of basic_iarchive) and see if the memory leaks disappear. Note that this is just a guess on my part, as I haven't had time to look at all the code in detail. In reference to the example you posted, you could change it to not use an empty shared_ptr but actually allocate an object for it and then change the deserialization code to: if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); ia.delete_created_pointers(); } Regards, Martin TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

Martin, <martin.ecker@tab.at> wrote in message news:OFDC881632.ACC5C7EF-ONC1256E8C.00370B68-C1256E8C.00375AC8@tab.at...
Jeff,
Although, I am having problems with my VC71 MFC application reporting memory leaks of a 24byte block corresponding to each shared_ptr loaded from an oarchive.
You probably mean "loaded from an iarchive".
I certainly did.
Anyway, due to the modifications I've made in our local code base of boost::serialization I had a bit of a look through the code.
I'm not sure, but the memory leaks you experience could possibly be related to the fact that basic_iarchive::delete_created_pointers is never called. Maybe you can add a call to this function yourself somewhere in your application (delete_created_pointers is a public member function of basic_iarchive) and see if the memory leaks disappear. Note that this is just a guess on my part, as I haven't had time to look at all the code in detail.
I've tried this with both the example and with my actual code, but end up in an infinite loop in the scoped_lock constructor in boost::detail::sp_counted_base::release, when the shared_ptr is destroyed. I've instrumented my class constructors/destructors and can see that the proper number of constructions/desctructions take place. So I don't think basic_iarchive::delete_created_pointers is the problem here. I'm trying to track down where the memory is allocated, but vc debugger is not cooperating. It's only reporting the block number, which of course is different each time I run. So I can't do a break and get the actual location the allocation is occuring.
In reference to the example you posted, you could change it to not use an empty shared_ptr but actually allocate an object for it and then change the deserialization code to:
if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn );
ia & boost::serialization::make_nvp( "SomeClass", lSomeClass ); ia.delete_created_pointers(); }
Using the fix you previously posted for boost::serialization::shared_ptr_access static void add_ref_copy(boost::detail::sp_counted_base * t){ if(t) t->add_ref_copy(); }; Fixed the NULL shared_ptr access violation I was seeing. Thanks, Jeff
participants (2)
-
Jeff Flinn
-
martin.ecker@tab.at