Re: Crashes and memory corruption

#1

Björn Persson wrote:

Quote:

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.

Quote:

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".)

Quote:

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:

perator[] in the refman.

Quote:

#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.

Quote:

#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.

Quote:

#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.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#2

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:

Quote:

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

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#3

Björn Persson wrote:

Quote:

I'm pretty sure you don't want any patches from me until I actually know
something that isn't documented. :-)

The best way to learn something thoroughly is to put yourself in a
position where you must explain it to someone else. I've probably
learned more about MySQL++ since I started updating the documentation
than in the prior year or so of just using it.

Quote:

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?

I don't know. Boil the problem you are seeing down to a small test
case, and I will know if it's a documentation weakness or a MySQL++ bug.

Quote:

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.

Perhaps, but I'll bet you're capable of acquiring that experience.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#4

BjÃ¶rn Persson wrote:

Quote:

Here's a program that does just that â€“ gets a Row and reuses the Result. Then
it tries to use the Row object, but the expected data isn't there.

I apologize for taking so long to get back to you on this.

If you look at the implementation for Row::at(), you will immediately
see why this happens. Basically, to construct the ColData object that
you are requesting, it needs to ask the result object for the list of
field types returned in the result set. The Row object could maintain a
copy of this, but that would be inefficient when dealing with large
result sets.

For now, I've just documented this requirement in the reference manual.
If you can think of a clean way for at() to avoid the need to access
the result object, I'll certainly entertain proposals or patches.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#5

I have had got the same problems, the same gdb-backtraces, and I think
it's inside the ResUse-deconstructor.
It calls purge() which contains:

"*delete* names_;
names_ = 0;
*
delete* types_;
types_ = 0;"

The problem is, that "names_" and "types_" are not neccessayrily
initialized with "new".

Since I changed the code like this:

" *if* (names_)
{
*delete* names_;
names_ = 0;
}

*if* (types_)
{
*delete* types_;
types_ = 0;
}

", everything works perfect.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#6

On Tue, Dec 20, 2005 at 08:45:58PM +0100, Jan Busch wrote:

Quote:

The problem is, that "names_" and "types_" are not neccessayrily
initialized with "new".

Since I changed the code like this:

" *if* (names_)
{
*delete* names_;
names_ = 0;
}

*if* (types_)
{
*delete* types_;
types_ = 0;
}

If the if statements fix a crash, then the bug is somewhere else.
Doing:
Object *ptr = 0;
[some code]
delete ptr;
ptr = 0;

.... is valid C++.

What compiler are you using?

- Chris

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

#7

Quote:

What compiler are you using?
g++ 4.0.3

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: Crashes and memory corruption

mailing.database.mysql-plusplus mailing.database.mysql-plusplus

Re: Crashes and memory corruption - 08-17-2005 , 11:46 AM

Re: Crashes and memory corruption - 08-18-2005 , 06:39 AM

Re: Crashes and memory corruption - 08-18-2005 , 12:20 PM

Re: Crashes and memory corruption - 12-15-2005 , 07:53 AM

Re: Crashes and memory corruption - 12-20-2005 , 01:46 PM

Re: Crashes and memory corruption - 12-20-2005 , 03:18 PM

Re: Crashes and memory corruption - 12-20-2005 , 09:39 PM