Well, I spent a large number of hours since my original message, and while I learned a lot, I could not solve my problem and I am about to give up using Boost. Here is what I managed to find out: - first an foremost, the example works fine when compiled and run from the terminal using the following command: c++ demo.cpp -o demo /usr/local/lib/libboost_serialization.dylib - the crash happens when running the example from the XCode IDE. Since my real project is developed using XCode, this is a show-stopper. - clearly, this is a Mac specific issue. I suspect something stupid, such as a build setting or something, but I could not find what. I posted requests for help on the XCode mailing list, but judging by the suggestions I got, Boost is not very popular with Mac developers. - So if somebody has managed to set up a working project under XCode (version 3.2 preferably), I'd be really interested in that. Now to the crash: I downloaded the source code the Mac version of the standard C++ library and for its malloc/free routine. Using that, I managed to reconstruct what's happening: 1- Boost allocate a new object of the sample code class bus_stop_corner. It's properly constructed, and its strings are initialized to empty std::string 2- Before reading the text for the street1 std::string, Boost calls std::string:resize() to size it to the correct length (11 in the sample run). 3- resize() sees that the new size is larger than the previous size (which was 0), and so calls std::string:append() to append some memory at the end. 4- append() sees that the new length is larger than the old string capacity and calls td::string:reserve() 5- reserve() clones the old string into a newly allocated larger buffer, of the size requested, and then calls _M_dispose() on the old buffer. Here is its source code: template<typename _CharT, typename _Traits, typename _Alloc> void basic_string<_CharT, _Traits, _Alloc>:: reserve(size_type __res) { if (__res != this->capacity() || _M_rep()->_M_is_shared()) { // Make sure we don't shrink below the current size if (__res < this->size()) __res = this->size(); const allocator_type __a = get_allocator(); _CharT* __tmp = _M_rep()->_M_clone(__a, __res - this->size()); _M_rep()->_M_dispose(__a); _M_data(__tmp); } } 6- _M_rep()->_M_dispose() calls _M_destroy() 7- _M_destroy() calls deallocate() (a method on the allocator) on the _M_rep() buffer 8- deallocate() calls the standard operator delete on its argument. void deallocate(pointer __p, size_type) { ::operator delete(__p); } 9- delete calls the standard C routine free(), which is defined in malloc.c: void free(void *ptr) { malloc_zone_t *zone; size_t size; if (!ptr) return; zone = find_registered_zone(ptr, &size); if (!zone) { malloc_printf("*** error for object %p: pointer being freed was not allocated\n" "*** set a breakpoint in malloc_error_break to debug\n", ptr); malloc_error_break(); if ((malloc_debug_flags & (SCALABLE_MALLOC_ABORT_ON_CORRUPTION| SCALABLE_MALLOC_ABORT_ON_ERROR))) abort(); } else if (zone->version >= 6 && zone->free_definite_size) malloc_zone_free_definite_size(zone, ptr, size); else malloc_zone_free(zone, ptr); } 10- the error occurs because free() cannot find the zone from which the string buffer was allocated. At this point I give up: I checked that the std::string whose buffer is deallocated was indeed properly constructed, ie that its buffer was allocated in a normal way: pointer allocate(size_type __n, const void* = 0) { if (__builtin_expect(__n > this->max_size(), false)) std::__throw_bad_alloc(); return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp))); } To go further I would need to get deep into the malloc implementation. Since the same code is running fine when built from the terminal, I suspect this would be fruitless. I'm open to suggestions, but a this point, I throw in the towel. Jean-Denis On Sep 20, 2009, at 21:04 , Robert Ramey wrote:
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