List:MySQL++« Previous MessageNext Message »
From:Graham Reitz Date:November 27 2007 5:01am
Subject:Re: Query object seg. faults on destruction...
View as plain text  
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
>


Thread
Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder021 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young22 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder026 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young26 Nov
    • Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Graham Reitz27 Nov
      • Re: Query object seg. faults on destruction...Graham Reitz27 Nov
        • Re: Query object seg. faults on destruction...Warren Young27 Nov
          • Re: Query object seg. faults on destruction...Graham Reitz27 Nov
            • Re: Query object seg. faults on destruction...Warren Young27 Nov
              • Re: Query object seg. faults on destruction...Graham Reitz28 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder027 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young27 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder028 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young28 Nov