Re: [Boost-users] Serialization demo program crashes trying to free anunallocated block

Subject: Re: [Boost-users] Serialization demo program crashes trying to free anunallocated block
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-09-20 15:04:49

I tried it on my system with both msvc-7.11 and gcc-4.3.2 (under cygwin)
and it worked fine. I used bjam to build and test it.

Robert Ramey

Jean-Denis Muys wrote:
> 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