[Boost-users] Serialization demo program crashes trying to free an unallocated block

Subject: [Boost-users] Serialization demo program crashes trying to free an unallocated block
From: Jean-Denis Muys (jdmuys_at_[hidden])
Date: 2009-09-19 17:39:07

Hi,

Warning: noob inside. I am new to boost, and quite a bit rusty with C+ 
+, having spent the past few years with other languages.

Nonetheless.

I downloaded, built and installed Boost 1.40 just fine on Mac OS X  
10.6 (Snow Leopard).

I set up a XCode 3.2 project to compile and run the demo.cpp program  
delivered with the Serialization library.

It crashes deep inside this line:

     restore_schedule(new_schedule, filename.c_str());

GDB gives the following error message:

malloc: *** error for object 0x1000581a0: pointer being freed was not  
allocated

The stack crawl shows:

#0	0x7fff81202ff6 in __kill
#1	0x7fff812a4072 in abort
#2	0x7fff811bb095 in free
#3	0x7fff836031e8 in std::string::reserve
#4	0x7fff836032fe in std::string::append
#5	0x10028ccac in  
boost 
::archive::text_iarchive_impl<boost::archive::text_iarchive>::load at  
text_iarchive_impl.ipp:55
#6	0x100024a5e in  
boost 
::archive::load_access::load_primitive<boost::archive::text_iarchive,  
std::string> at iserializer.hpp:109
#7	0x100024a83 in  
boost 
::archive 
::detail::load_non_pointer_type<boost::archive::text_iarchive,  
std::string>::load_primitive::invoke at iserializer.hpp:332
#8	0x100024aa8 in  
boost 
::archive 
::detail::load_non_pointer_type<boost::archive::text_iarchive,  
std::string>::invoke at iserializer.hpp:417
#9	0x100024acd in boost::archive::load<boost::archive::text_iarchive,  
std::string> at iserializer.hpp:542
#10	0x100024afe in  
boost 
::archive 
::detail 
::common_iarchive 
<boost::archive::text_iarchive>::load_override<std::string> at  
common_iarchive.hpp:61
#11	0x100024b2b in  
boost 
::archive 
::basic_text_iarchive 
<boost::archive::text_iarchive>::load_override<std::string> at  
basic_text_iarchive.hpp:62
#12	0x100024b59 in  
boost 
::archive 
::text_iarchive_impl 
<boost::archive::text_iarchive>::load_override<std::string> at  
text_iarchive.hpp:66
#13	0x100024b8c in  
boost 
::archive 
::detail 
::interface_iarchive 
<boost::archive::text_iarchive>::operator>><std::string> at  
interface_iarchive.hpp:61
#14	0x100024bc3 in  
boost 
::archive 
::detail 
::interface_iarchive 
<boost::archive::text_iarchive>::operator&<std::string> at  
interface_iarchive.hpp:68
#15	0x100026688 in  
bus_stop_corner::serialize<boost::archive::text_iarchive> at main.cpp: 
123
#16	0x1000266c3 in  
boost::serialization::access::serialize<boost::archive::text_iarchive,  
bus_stop_corner> at access.hpp:109

and so on...

The last frame for which I have source code is #5. There the crashes  
occurs in the following routine:

template<class Archive>
BOOST_ARCHIVE_DECL(void)
text_iarchive_impl<Archive>::load(std::string &s)
{
     std::size_t size;
     * this->This() >> size;
     // skip separating space
     is.get();
     // borland de-allocator fixup
     #if BOOST_WORKAROUND(_RWSTD_VER, BOOST_TESTED_AT(20101))
     if(NULL != s.data())
     #endif
         s.resize(size);	// <============== crash here
     if(0 < size)
         is.read(&(*s.begin()), size);
}

In that frame, s is the empty string (its internal buffer points to a  
0 byte), and size is 11.

Suspecting a bug in OS X std::string class, I checked that the  
following program works fine:

int main()
{
        std::string s;
        std::size_t size = 11;
        std::cout << s << std::endl;
        s.resize(size);	
        std::cout << s << std::endl;
}

So I tried to follow the stack up tracking the string object to see  
where and how it was created. I lost track of it in frame #15 on the  
following line:

         ar & street1 & street2;

Note that this is back to the sample code.

I decided to split that line into two lines, and surely now the  
crashes occurs there:

         ar & street1;

I'm going to go on tracing through that, but maybe this rings a bell  
with someone, that would save me time... I can post more info if needed.

Best regards and thanks,

Jean-Denis