List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:August 17 2005 4:46pm
Subject:Re: Crashes and memory corruption
View as plain text  
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, 

> 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.
Crashes and memory corruptionBjörn Persson16 Aug
  • Re: Crashes and memory corruptionWarren Young16 Aug
    • Re: Crashes and memory corruptionBjörn Persson17 Aug
      • Re: Crashes and memory corruptionWarren Young17 Aug
        • Re: Crashes and memory corruptionBjörn Persson18 Aug
          • Re: Crashes and memory corruptionThomas Werth18 Aug
          • Re: Crashes and memory corruptionWarren Young18 Aug
        • Re: Crashes and memory corruptionBjörn Persson25 Nov
          • Re: Crashes and memory corruptionWarren Young15 Dec
            • Re: Crashes and memory corruptionBjörn Persson15 Dec
Re: Crashes and memory corruptionJan Busch20 Dec
  • Re: Crashes and memory corruptionChris Frey20 Dec
Re: Crashes and memory corruptionJan Busch21 Dec