List:MySQL++« Previous MessageNext Message »
From:Thomas Werth Date:August 18 2005 11:38am
Subject:Re: Crashes and memory corruption
View as plain text  
Just wanna confirm this bogus behaviour. I guess this problem has some
relationship to my post "problems using mysql++ > 2.0.0". Nevertheless
i'm stuck , too. I guess it must have to do something with linking /
settings of library and use of due different stacks when using dynamic
libs. For static problem vanishes due using same stack.
Maybe answear to my post will bring solution for your prob too.

Björn Persson schrieb:
> onsdagen den 17 augusti 2005 18:46 skrev Warren Young:
> 
>>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.
> 
> 
> I'm pretty sure you don't want any patches from me until I actually know 
> something that isn't documented. :-)
> 
> 
>>>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.
> 
> 
> Interesting. The question is then: What caused the problems I had earlier, and 
> why did they go away when I stopped returning Results and Rows from 
> functions? Maybe that was the same bug that's causing my current problem. In 
> that case it's not a new bug in GCC 4 for example, as I had GCC 3.4 then.
> 
> 
>>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.
> 
> 
> Yes, but I lack the necessary experience. I was hoping someone who's familiar 
> with the internals of MySQL++ would be able to help me find the problem, or 
> that others would have the same problem and know more about it.
> 
> 
>>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.
> 
> 
> That's very probable, especially with those alerts from GlibC taken into 
> account.
> 
> 
>>Try running your program under valgrind, or your favorite memory debugger.
> 
> 
> I'm afraid I don't have a favorite memory debugger as I've never used one. 
> I've heard mentions of Valgrind. I'll see when I can find the time to try it.
> 
> Björn Persson
> 
Thread
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