As a quick follow up, the valgrind showing ??? on dlopened modules
problem exists in MySQL and Mariadb as well... so it seems to be
something intrinsic to valgrind and dlopen. Still looking for solutions
though...
On 04/10/2010 01:20 AM, Monty Taylor wrote:
AAHHHHHHHHHHHHHHHHHHHHHHHH
This makes 100% sense now. (although I do not have a fix that stewart is
going to like at the moment)
Read below.
On 04/09/2010 01:11 AM, Brian Aker wrote:
Hi!
On Apr 8, 2010, at 7:45 PM, orisndriz08 wrote:
=21400== 64 bytes in 1 blocks are indirectly lost in loss record 16 of
170
==21400== at 0x4C25153: malloc (vg_replace_malloc.c:195)
==21400== by 0x9D4E3C8: ???
==21400== by 0x9D4F950: ???
==21400== by 0x9D4FD7E: ???
==21400== by 0x9D512D9: ???
==21400== by 0x9D03C07: ???
==21400== by 0x9D088B8: ???
==21400== by 0x9CA68B5: ???
==21400== by 0x9D3452A: ???
==21400== by 0x9C754EB: ???
==21400== by 0x5B9BD3: plugin_init (loader.cc:340)
==21400== by 0x4F757F: main (drizzled.cc:1238)
This is leaking memory all over the place. It needs to be fixed pretty
badly at this point.
The leak was introduced in rev 1449. Funnily enough - this is the rev
that introduced embedded_innodb. It's not embedded_innodb's fault per se
though... it's making innodb build dynamic rather than static...
What we do? I am fine with requiring the server be built entirely
statically until this is fixed, which I believe is an option.
So, sadly, this is what it looks like when a plugin is leaking memory.
(I Consider this a bug in valgrind as it relates to dlopen()) I just
dealt with this while tracking down that leak in the transaction_log
plugin. I would love to solve this - so far I've been unable to put
together a small enough test case that reproduces this problem in
valgrind to send to them. According to them, this should not happen with
dlopen stuff... except that it does.
HERE'S THE PROBLEM:
InnoDB is horribly not valgrind clean- we have a bazillion valgrind
suppressions in the suppressions file for this reason.
The problem is, valgrind can't match symbols properly when we're
dlopen()ing (see above issue with valgrind - I will try harder to find a
bug or a solution to that) SO - all of our innodb suppressions become
useless.
All of them.
We can't have normally innodb be static and also use embedded innodb
because of symbol clashes (you probably just discovered this in your
test tree)
So I'm going to suggest (as much as this makes me sad) that we back
embedded_innodb out of the tree and set innodb back to static=yes until
we can solve the valgrind issue -otherwise valgrind is going to be
useless to us.
Monty
PS. Sorry I did not respond to this sooner - I missed the mail message.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-benchmark
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-benchmark
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-benchmark
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-benchmark
More help : https://help.launchpad.net/ListHelp
