Hi Kristian, On Tue, Mar 09, 2010 at 04:11:26PM +0100, Kristian Nielsen wrote:

Thanks for offering to help with the memory leak. Here are the details.

Tree is here:

lp:~maria-captains/maria/mariadb-5.1-knielsen

This tree is the merge with MySQL-5.1.44, including your fix for the uninitialised variable in table elimination.

The test case is the following, which is a simplified version of main.union (so main.union shows the same memory leak):

-------------------------------- cut here -------------------------------- CREATE TABLE t1 (a VARCHAR(10), FULLTEXT KEY a (a)); INSERT INTO t1 VALUES (1),(2); CREATE TABLE t2 (b INT); INSERT INTO t2 VALUES (1),(2);

EXPLAIN EXTENDED SELECT * FROM t1 UNION SELECT * FROM t1 ORDER BY (SELECT a FROM t2 WHERE b = 12);

DROP TABLE t1,t2; -------------------------------- cut here --------------------------------

Please find the fix below. The fix has a relatively high chance of breaking something (I've discovered that this kind of subqueries is processed in a way that would surprise pretty much everyone I think), so it's better to wait for a full buildbot run before we include it in the main tree. ----- Forwarded message from Sergey Petrunya ----- From: Sergey Petrunya To: maria-developers@lists.launchpad.net X-Mailer: mail (GNU Mailutils 1.2) Date: Tue, 9 Mar 2010 21:53:58 +0300 (MSK) Subject: [Maria-developers] Rev 2798: Fix a buildbot memory leak due to JOIN::destroy() not being called for EXPLAIN in file:///home/psergey/dev/mariadb-5.1-knielsen/ At file:///home/psergey/dev/mariadb-5.1-knielsen/ ------------------------------------------------------------ revno: 2798 revision-id: psergey@askmonty.org-20100309185356-ns7o30p75xjjby35 parent: knielsen@knielsen-hq.org-20100309150559-07zcnnz8dh54m2ug committer: Sergey Petrunya branch nick: mariadb-5.1-knielsen timestamp: Tue 2010-03-09 21:53:56 +0300 message: Fix a buildbot memory leak due to JOIN::destroy() not being called for EXPLAIN query: - When subquery is located in ORDER BY, EXPLAIN will run as follows: select_describe() will run JOIN::prepare()/optimize() for the subquery; then at some point subselect_single_select_engine::prepare() will be called, which will create another join and run join->prepare(). In mainline mysql this is not a problem because subquery's join will be destroyed after the first call. In MariaDB, it won't (table elimination needs to keep JOIN objects around for longer in order to know which tables were eliminated when constructing EXPLAIN EXTENDED warning). Fix the problem of memory leak by calling select_lex->cleanup() in subselect_single_select_engine::prepare(). === modified file 'sql/item_subselect.cc' --- a/sql/item_subselect.cc 2010-03-09 15:03:54 +0000 +++ b/sql/item_subselect.cc 2010-03-09 18:53:56 +0000 @@ -1776,6 +1776,10 @@ { if (prepared) return 0; + if (select_lex->join) + { + select_lex->cleanup(); + } join= new JOIN(thd, select_lex->item_list, select_lex->options | SELECT_NO_UNLOCK, result); if (!join || !result) _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ----- End forwarded message ----- BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog