Thanks again Warren,
> 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.
That makes sense.
I made a little bit of progress. I was statically linking the
libmysqlclient_r.a and dynamically linking the mysqlpp library. When
I dynamically linked both the memory alignment message is no longer
present.
Although, I don't understand why it should matter. So I added a few
more lines of code (below), which include a Connection object and
Query object. It seg. faults somewhere down below the ~Query
destructor but it doesn't make any sense to me why. I don't think it
is the Query object itself.
I built the mysql libraries from scratch but I didn't use Fink since
they didn't have a Leopard build. I should probably go ahead and
build Fink, since that's what I used when I had Tiger installed to get
the mysql client libs.
> 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?
I am using Xcode 3.0. It was a clean nuke-and-pave install.
Thanks again for your help. I will go ahead and grab fink and see if
that helps. Do you see anything else ?
Here is the updated code (below is the gdb output)
#include <iostream>
#include <string>
#include <mysql++.h>
using namespace std;
using namespace mysqlpp;
int main (int argc, char * const argv[])
{
string database_name = "db_rev_4";
string ip_address = "xx.xx.xx.xx";
string username = "admin";
string password = "admin";
string client_id = "graham";
string client_pw = "reitz";
string error_msg;
cout << "Attempting to connect to the database...";
Connection connection(database_name.c_str(),
ip_address.c_str(),
username.c_str(),
password.c_str(),
3306,
false,
15);
Result client_id_result;
try
{
cout << "connected to the database\n";
Query client_id_query = connection.query();
}
catch (exception &e)
{
cout << "exception occurred...";
cout << e.what() << endl;
}
catch (...)
{
error_msg = "Unknown exception";
cout << error_msg << endl;
}
connection.close();
return 0;
}
gdb output:
GNU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49
UTC 2007)
This GDB was configured as "i386-apple-darwin"...Reading symbols for
shared libraries ....... done
(gdb) run
Starting program: /Users/grahamreitz/Development/mysqlpp_test/build/
Debug/mysqlpp_test
Reading symbols for shared libraries ++++++. done
Attempting to connect to the database...connected to the database
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffffc
0x92b7f6e1 in __gnu_cxx::__exchange_and_add ()
(gdb) backtrace
#0 0x92b7f6e1 in __gnu_cxx::__exchange_and_add ()
#1 0x92b6f070 in std::string::_Rep::_M_dispose ()
#2 0x92b704ab in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string ()
#3 0x000036ba in std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::~basic_stringbuf (this=0xbffff79c) at iosfwd:71
#4 0x00003725 in std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::~basic_stringbuf (this=0xbffff79c) at iosfwd:71
#5 0x00004d63 in mysqlpp::Query::~Query (this=0xbffff700) at query.h:
131
#6 0x00002723 in main (argc=1, argv=0xbffff8d4) at /Users/grahamreitz/
Development/mysqlpp_test/main.cpp:35
(gdb)
On Nov 26, 2007, at 10:31 PM, Warren Young wrote:
> 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?
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: http://lists.mysql.com/plusplus?unsub=1
>
