MySQL Bugs: #24086: Falcon crashes when index_merge

Bug #24086	Falcon crashes when index_merge_falcon is run multiple times
Submitted:	8 Nov 2006 12:34	Modified:	20 May 2007 5:37
Reporter:	Matthias Leich	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S1 (Critical)
Version:	5.2	OS:	Any
Assigned to:	Kevin Lewis	CPU Architecture:	Any

Description:
index_merge_falcon was successful within the last weeks.
Now it fails with a wrong result set:
-------------------------------------
The queries (around protocol line 
select t_vers,t_rele,t_cust,filler1 from t1 where t_vers = '7.6';
       and 	    	
select t_vers,t_rele,t_cust,filler1 from t1 where t_vers = '7.6'
  and t_rele='a' and t_cust = ' ';
get empty result sets instead of
t_vers	t_rele	t_cust	filler1
7.6 	a 	    	
7.6 	a

t_vers is defined as varchar(4) NOT NULL and is also part of
KEY `IX_5` (`t_vers`,`t_rele`,`t_cust`).

This bug is P1 because the testcase was successful in history.

My environment:
 - PC Intel Pentium M (x86-32Bit) with Linux(SuSE 10.1)
 - MySQL compiled from source
     mysql-5.1-falcon last ChangeSet@1.2369, 2006-11-08
     BUILD/compile-pentium-debug-max

How to repeat:
Just run 
./mysql-test-run.pl --skip-ndb index_merge_falcon

I just pushed a change that should finish the changes for BUG#23962 correstly.  This bug is a regression caused by the first set of changes pushed yesterday.

The StorageTable::compareKey() function needs to get the correct length of both the fields it is comparing.  It was not doin that when the field is in a multi-segmented key.

A single test run of index_merge_falcon passes for me now.
- mysql-5.1-falcon last ChangeSet@1.2359, 2006-11-12
- compile-pentium-debug-max
- Intel Pentium M (x86-32Bit)
- Linux (SuSE 10.1)

Note: A (!not all!) pushbuild run of index_merge_falcon failed with
index_merge_falcon             [ fail ]

Errors are (from /dev/shm/var-n_stm-130/log/mysqltest-time) :
mysqltest: In included file "./include/index_merge1.inc": At line 349: query 'drop table t0, t1, t2, t3, t4' failed: 1051: Unknown table 't1'
...

The reason for this failure is currently unclear and it does
not look like this failure is related to the current bug report/the fix.
The subtestcase related to the current bug is part of
    include/index_merge2.inc.
The subtestcase where a pushbuild run failed is part of
    include/index_merge1.inc.
index_merge1.inc is earlier than index_merge2 sourced/executed.

Change back to In Progress since it is still failing.

I think this was fixed previously.

Still failing randomly

TEST                           RESULT         TIME (ms)
-------------------------------------------------------

index_merge_falcon             [ pass ]          18959
index_merge_falcon             [ pass ]          20977
index_merge_falcon             [ pass ]          17750
index_merge_falcon             [ pass ]          13251
index_merge_falcon             [ pass ]          17548
index_merge_falcon             [ pass ]          13581
index_merge_falcon             [ fail ]

Errors are (from /home/hakan/work/mysql/mysql-5.1-falcon/mysql-test/var/log/mysqltest-time) :
mysqltest: In included file "./include/index_merge2.inc": At line 137: query 'drop table t1,t2' failed: 2013: Lost connection to MySQL server during query
(the last lines may be the most important ones)
Result from queries before failure can be found in /home/hakan/work/mysql/mysql-5.1-falcon/mysql-test/var/log/index_merge_falcon.log

Aborting: index_merge_falcon failed in default mode. To continue, re-run with '--force'.
Stopping All Servers

The current complaint for this bug is that the engine dies if you run the testcase repatedly.  I ran it for 4 sets of 10 repetitions and it died twice at an ASSERT that happens in DROP TABLE (once on the 4th iteration and once on the 5th).  

The assert is in the destructor of a record for new code which tried to determine if the record is still active when it is destroyed.  This code is defined by CHECK_RECORD_ACTIVITY.  Either this debugging/validation code is missing a (active = false) somewhere or the record being deleted is really active.  But this happens during DROP TABLE.

It should be noted that this is now a different bug than what was originally entered.

Renamed the Synopsis to reflect the current version of this bug.

I ran 25 succefull iterations on index_merge_falcon in a row.  I think this is fixed now. It is likely that the changes last week for Bug#28165 & Bug#27901 also fixed this problem since they both have to do with record version referencing.

I can't repeat the failure anymore.

I could verify 82 successful runs of index_merge_falcon:

index_merge_falcon             [ pass ]          18989
index_merge_falcon             [ pass ]          18499
index_merge_falcon             [ pass ]          18371
index_merge_falcon             [ pass ]          17627
index_merge_falcon             [ pass ]          18080
index_merge_falcon             [ pass ]          18566
index_merge_falcon             [ pass ]          18380
index_merge_falcon             [ pass ]          18483
index_merge_falcon             [ pass ]          17291
-------------------------------------------------------
All 82 tests were successful.
The servers were restarted 1 times
Spent 1516.555 seconds actually executing testcases

No note required for the changelog (internal). Closing.