From: Warren Young
Date: August 17 2005 4:46pm
Subject: Re: Crashes and memory corruption
List-Archive: http://lists.mysql.com/plusplus/4760
Message-Id: <430369D4.3020000@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Björn Persson wrote:
> 
> I had problems earlier that seemed to be caused by dangling pointers, and the 
> documentation wasn't very clear on which methods return copies of data and 
> which return pointers, 

So send a patch.  The documentation doesn't fix itself.

> So a Result object has no pointers into the Query object then? 

A simple grep answers this question.  (For the impatient, the answer is, 
"no".)

> But I have to 
> keep the Result until I'm done with all Row and ColData objects, don't I?

Probably not.  For example, Result::at() plainly returns Rows by value. 
  If you get a Row object, and are then done retrieving results, you can 
reuse the Result object.

ColData objects, similarly, are returned by value from Row objects.

The only "dangling pointer" problem I'm aware of in MySQL++ has to do 
with ColData and conversions, and this one is documented under 
Row::operator[] in the refman.

> #0  0x004c4da6 in __gnu_cxx::__mt_alloc<mysqlpp::mysql_type_info, 
> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate 
> (this=0x9c4c660, __n=2) 
> at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
> #1  0x004c9626 in mysqlpp::ResUse::copy (this=0xbfc2ad50, other=@0xbfc2ae28) 

You're in a better position to debug this than I am...a live program 
yields more info than the backtrace of a dead one.  But the fact that 
the program bombs while trying to do some kind of allocation suggests 
that the heap may already be scragged.  You may be viewing secondary damage.

Try running your program under valgrind, or your favorite memory debugger.

> #0  0x0804fc40 in __gnu_cxx::__mt_alloc<std::string, 
> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate 
> (this=0xbf8ce54c, __n=15) 
> at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
> #1  0x0804fcad in std::_Vector_base<std::string, std::allocator<std::string> 

Same issue, looks like to me.

> #0  0x0805106c in __gnu_cxx::__mt_alloc<std::string, 
> __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate 
> (this=0xbffba8d8, __n=2) 
> at /usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:719
> #1  0x080510d9 in std::_Vector_base<std::string, std::allocator<std::string> 

...and again here.