Re:[boost] "memory access violation" in boost::serialization

I presume you are using serialization draft # 18 upload last april. Since then helpful users have found a couple of bugs which I have subsequently fixed. There is a more recent version that I have tested with boost 1.31 at www.rrsd.com. It is labeled serialization #20. I am currently struggling - so far with only limited success - in getting the most recent version of the serialization library checked in to the main boost CVS. This as been too slow to get it done but too fast to give up on. Regarding your particular problem, I believe that this came up under the the condition where a n object is saved through a pointer to its base class and it was not registered or exported. This has been addressed in the current library by throwing an exception. Of course this helps characterize the problem - but it doesn't really fix the cause. This latter one has to do himself. BTW, there have been a couple of other small bug fixes related to some collections (hmm - map was among them!)- this might or might not address your symptoms. Another bug in the serialization of shared_ptr was uncovered which was causing a memory leak. I hope all this helps. Thanks for the feedback. As an aside - I notice that I'm getting about 300 downloads/month of the serialization package from my web site. I have no information about downloads from the Yahoo/Boost files area - (which I would be curious to know). I get very little feedback - I'm wondering if lots of downloaders take a look and decide it's too complex to actually use. Robert Ramey
Hi,
I encountered the following little problem:
I would like to use the following datastructures with boost::serialize:
struct Match {}; typedef std::string Key; typedef tst< Match, Key > TernarySearchTree; //this one has a shared_ptr
typedef std::vector< TernarySearchTree > Trees; typedef std::map< std::string, Trees > Symbols;
I have defined some serialize overloads so saving goes fine, but when loading I get a "memory acces violation" inside the following code:
{ boost::archive::text_iarchive ia(ifs); ia >> symbols_; }
More specific, inside <boost/serializiton/shared_count.hpp>
void add_ref_copy() { #if defined(BOOST_HAS_THREADS) mutex_type::scoped_lock lock(mtx_); #endif ++use_count_; }
Which constructs a scoped_lock, and there, the "explicit scoped_lock(lightweight_mutex & m): m_(m)" seems to go wrong.
What could be the reason? The more since all worked fine (saving and loading) when I used a simple vector of tst's.
Is it not possible to use a map of string/vector (the error seems to suggest the library failing when copying vector to map - eg ++use_count of the shared_ptr inside the TST).

Robert, "Robert Ramey" <ramey@rrsd.com> wrote in message news:20040712165416.36BCB318E9@acme.west.net...
I presume you are using serialization draft # 18 upload last april. Since then helpful users have found a couple of bugs which I have subsequently fixed. There is a more recent version that I have tested with boost 1.31 at www.rrsd.com. It is labeled serialization #20.
I am currently struggling - so far with only limited success - in getting the most recent version of the serialization library checked in to the
boost CVS. This as been too slow to get it done but too fast to give up on.
Regarding your particular problem, I believe that this came up under the
I just downloaded #20. I'll give try it with my applications and let you know if there are any issues. main the
condition where a n object is saved through a pointer to its base class and it was not registered or exported. This has been addressed in the current library by throwing an exception. Of course this helps characterize the problem - but it doesn't really fix the cause. This latter one has to do himself.
I really think the issue is with the weak_count in shared_ptr.hpp as described in my response to Dirk. Hopefully he'll let us know if that solved his problem.
BTW, there have been a couple of other small bug fixes related to some collections (hmm - map was among them!)- this might or might not address your symptoms. Another bug in the serialization of shared_ptr was uncovered which was causing a memory leak. I hope all this helps.
Thanks for the feedback.
As an aside - I notice that I'm getting about 300 downloads/month of the serialization package from my web site. I have no information about downloads from the Yahoo/Boost files area - (which I would be curious to know). I get very little feedback - I'm wondering if lots of downloaders take a look and decide it's too complex to actually use.
I've seen several postings in comp.lang.c++* and microsoft...vc.* over the last few months. I'm also guilty of doing a little evangelizing there. Robert, your being a little pessimistic. Could be that many are using it without problem. :-) My initial uses even way back with #12(or there abouts) were successful. Albeit, I only needed to exercise simpler facets such as serialization of non-polymorphic classes and built-in data types. Certainly, your approach is much more intuitive/flexible/... than MFC's. ----------------- Jeff Flinn Applied Dynamics, International

On Mon, 12 Jul 2004 14:52:17 -0400, Jeff Flinn <triumphsprint2000@hotmail.com> wrote:
Robert,
"Robert Ramey" <ramey@rrsd.com> wrote in message news:20040712165416.36BCB318E9@acme.west.net...
As an aside - I notice that I'm getting about 300 downloads/month of the serialization package from my web site. I have no information about downloads from the Yahoo/Boost files area - (which I would be curious to know). I get very little feedback - I'm wondering if lots of downloaders take a look and decide it's too complex to actually use.
I've seen several postings in comp.lang.c++* and microsoft...vc.* over the last few months. I'm also guilty of doing a little evangelizing there. Robert, your being a little pessimistic. Could be that many are using it without problem. :-) My initial uses even way back with #12(or there abouts) were successful. Albeit, I only needed to exercise simpler facets such as serialization of non-polymorphic classes and built-in data types. Certainly, your approach is much more intuitive/flexible/... than MFC's.
Robert, I'm using in some apps on win32 vc7.1 and the biggest complement I can give is, "It just works." Thanks for you effort, especially after that first tortuous review. Regards, Matt Hurd.
participants (3)
-
Jeff Flinn
-
Matt Hurd
-
Robert Ramey