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?
