Comment 29 for bug 758788

Just some more info, logging it here in case I forget or for anyone following. I can easily hit my assertion that I added above and removing that assertion I can 100% recreate an error situation by executing the following sql script:

SET GLOBAL innodb_dict_size_limit=1;
SET LOCAL AUTOCOMMIT=OFF;
BEGIN;
CREATE TABLE test.t1 (c1 INT) ENGINE=INNODB;
CREATE TABLE test.t2 (c1 INT) ENGINE=INNODB;
INSERT INTO test.t1(c1) VALUES(1);
FLUSH TABLES;
INSERT INTO test.t2(c1) VALUES(1);
COMMIT;

The 'FLUSH TABLES' command above allows the eviction of the dict_table for t1 in the dict cache even though there is a lock held against it and referenced from the transaction lock list. When the COMMIT comes along and tries to clean up the transaction lock list, the reference to t1 that was locked during the first insert is now completely invalid and can cause various assertions since it is now pointing to potentially reclaimed memory.

From digging, there seems to be a disconnect between what mysql thinks of as an 'unused table' (where it pulls the list of TABLES that it can/should flush) and what XtraDB believes are used. There seems to be no way to fail to 'close' the table at the handler interface within XtraDB so somehow I need to figure out why MySQL thinks this table is 'unused' when in fact it is most certainly being used. Stay tuned...