Description:
This test failure seems to be new in the 5.5.6-m3 release build.
It is specific to the platform Linux/x86/ICC and happens in the "embedded" test run only.
Given the identical platform, it might be related to bug#52419, but other than the platform and the inconsistency in the messages I have no hard evidence for this.
=====
main.lock_tables_lost_commit [ fail ]
Test ended at 2010-09-02 19:57:13
CURRENT_TEST: main.lock_tables_lost_commit
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use InnoDB's own implementation
InnoDB: Compressed tables use zlib 1.2.3
100902 20:57:06 InnoDB: Using Linux native AIO
100902 20:57:06 InnoDB: highest supported file format is Barracuda.
mysqltest: At line 17: query 'INSERT INTO t1 VALUES(10)' failed: 1100: Table 't1' was not locked with LOCK TABLES
The result from queries just before the failure was:
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(a INT) ENGINE=innodb;
LOCK TABLES t1 WRITE;
Warnings from just before the error:
Note 1051 Unknown table 't1'
- saving '/export/home2/pb2/test/sb_2-2235639-1283447973.31/mysql-5.5.6-rc-linux2.6-i686-icc/mysql-test/var/log/main.lock_tables_lost_commit/' to '/export/home2/pb2/test/sb_2-2235639-1283447973.31/mysql-5.5.6-rc-linux2.6-i686-icc/mysql-test/var/log/main.lock_tables_lost_commit/'
Retrying test, attempt(2/3)...
=====
So the sequence is "create", "lock", insert", all about table "t1";
the warning "unknown table" seems to come with the "lock" just after "create",
and then "insert" fails due to a missing lock.
Further in the test suite, there are more failures where "was not locked" is claimed.
How to repeat:
Run the suite on this platform, in "embedded" mode.
Suggested fix:
Do ICC builds in PB2 for faster problem discovery.
