Have figured it out!!!!!!!!!!!!!
(thanks go to knielsen for helping me look)
The ??? lines come because valgrind reports memory leaks at program
close. Of course, at program close, we've dlclose()'d all of our
plugins, because we're good and clean up after ourselves. :)
Removing dlclose() makes the valgrind stack traces work. I'm going to
make a new suggestion:
Remove the rev from build that turns everything to static. Don't remove
embedded_innodb. Removed (for now) the dlclose() calls from the
drizzled::plugin::Library destructor- since we don't dynamically unload
plugins, this is not nearly as big a deal as valgrind being broken for us.
With that done, I can put in a dlclose valgrind suppression and make
sure that the suppression are working properly for innodb as non-static.
In fact - if this fixes the base problem - we might _actually_ be able
to suppress all the shitty innodb issues once and for all...
I'm going to go to bed soon - but I will have a tree soon that shows
this as a POC. At the very least, even if my tree doesn't clean the
innodb errors - at least it will accurately show where the FUCK the
errors actually are.
Monty
PS. SO HAPPY I finally grok why the valgrind output has been borked.
On 04/10/2010 01:51 AM, Monty Taylor wrote:
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
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-benchmark
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-benchmark
More help : https://help.launchpad.net/ListHelp
