From: Warren Young
Date: November 27 2007 4:31am
Subject: Re: Query object seg. faults on destruction...
List-Archive: http://lists.mysql.com/plusplus/7185
Message-Id: <474B9DBE.60707@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Graham Reitz wrote:
> 
> "mysqlpp_test(386) malloc: *** error for object 0x189fd8: Non-aligned 
> pointer being freed
> *** set a breakpoint in malloc_error_break to debug"

This is a 64-bitness type of thing.  Like one part of the code is built 
for 32-bit, the other for 64, and the 32-bit side allocates something it 
expects the 64-bit side to free.  All works fine as long as the 32-bit 
side's allocation addresses are "even" in 64-bit terms.

> Could this have something to do with how the mysqlpp dylib is getting 
> built on leopard?  Does anyone here have a mac with leopard on it that 
> can try this? 

I have run the svn version on Leopard machines a few times recently, 
both Intel and PPC.  I didn't notice anything odd.  I don't know that 
this proves anything about 2.3.2, but it's at least suggestive.  Also, 
your test program builds against the svn version as well, on PPC at 
least.  I don't have the wherewithal to try it on Intel, or against 
2.3.2 right now.

I'm using the Fink version of MySQL 5.0, for what that's worth.  Being 
Leopard, this means I'm using the bleeding edge "bootstrap" version of 
Fink, which in turn means MySQL is being built from source, not 
installed as a binary.

There was a thread on the main MySQL list recently about MySQL not 
working right under Leopard, and he was building MySQL directly from 
source, not via Fink.  Maybe the Fink folk have figured out something 
about building MySQL that hasn't been folded into the toplevel source 
distribution yet?

> (gdb) backtrace
> #0  0x926c69f1 in malloc_error_break ()
> #1  0x926c19df in szone_error ()
> #2  0x925e6b83 in szone_free ()
> #3  0x925e69ed in free ()
> #4  0x92b6f02a in std::string::_Rep::_M_destroy ()
> #5  0x92b704ab in std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >::~basic_string ()

This argues against it being a problem with MySQL++: the error is in 
std::string.  Since we don't see a line number for ~ResUse() in the next 
line of the backtrace, it suggests the error is happening in code 
generated by the C++ compiler, so my guess is that we're seeing the 
failure during the destruction of ResUse::table_.  Weirdness in the 
generated binary somewhere is most likely.

Are you using Xcode 3.0?  Is this an upgrade to Leopard or a fresh 
install?  If "fresh", how fresh?  Nuke-and-pave, or archive-and-install?