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,
> > 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
That's very probable, especially with those alerts from GlibC taken into
> 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.