MySQL Bugs: #27767: Falcon: crash after select for update

Bug #27767	Falcon: crash after select for update
Submitted:	11 Apr 2007 20:17	Modified:	26 Apr 2007 10:58
Reporter:	Peter Gulutzan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S2 (Serious)
Version:	5.2.4-falcon-alpha-debug	OS:	Linux (SUSE 10 64-bit)
Assigned to:		CPU Architecture:	Any

Description:
I create a Falcon table with an indexed column.
I insert one row.
On another connection, I say SELECT ... FOR UPDATE.
Crash.

How to repeat:
Clear datadir directory and run mysql_install_db,
then start mysqld. Do not use an already-existing
datadir. Do not use an already-up mysqld.

Start two mysql client connections, T1 and T2.

On T1, say:
use test
drop database d;
create database d;
use d
create table t (s1 int) engine=falcon;
set @@autocommit=0;
create index i on t (s1);
insert into t values (6);
commit;

(The above statements might cause irreproducible crashes.
If you encounter such crashes, just ignore them and re-do
all steps.)

On T2, say:
use d
set @@autocommit=0;
select * from t where s1 = 6 for update;

Thank you for the bug report. Verified as described on FC 6.0 32-bit.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1308927088 (LWP 7928)]
0x084b14dc in NfsStorageTable::external_lock (this=0xb0d4418, thd=0xb0b9510, lock_type=1) at ha_falcon.cpp:1522
1522                            if (storageConnection->startTransaction(thd->variables.tx_isolation))
(gdb)

The occasional crashes which I called "irreproducible" turned out
to be reproducible, and are now described in a separate bug report:
Bug#27768 Falcon: crash if create database and create table

Still failing with following crash:

(gdb) bt
#0  StorageConnection::setCurrentStatement (this=0x0,
    text=0xe8b088 "select * from t where s1 = 6 for update") at StorageConnection.cpp:430
#1  0x000000000078c4f0 in NfsStorageTable::external_lock (this=0xe969b8, thd=0xe78f28, lock_type=1)
    at ha_falcon.cpp:1503
#2  0x00000000006e4969 in handler::ha_external_lock (this=0xe969b8, thd=0xe78f28, lock_type=1)
    at handler.cc:3610
#3  0x0000000000601647 in lock_external (thd=0xe78f28, tables=<value optimized out>, count=1) at lock.cc:261
#4  0x000000000060224a in mysql_lock_tables (thd=0xe78f28, tables=0xe8b898, count=1, flags=4,
    need_reopen=0x408c1957) at lock.cc:172
#5  0x000000000064b822 in lock_tables (thd=0xe78f28, tables=0xe8b240, count=<value optimized out>,
    need_reopen=0x408c1957) at sql_base.cc:3640
#6  0x000000000065336a in open_and_lock_tables (thd=0xe78f28, tables=0xe8b240) at sql_base.cc:3483
#7  0x0000000000613129 in execute_sqlcom_select (thd=0xe78f28, all_tables=0xe8b240) at sql_parse.cc:4427

(gdb) f 0
#0  StorageConnection::setCurrentStatement (this=0x0,
    text=0xe8b088 "select * from t where s1 = 6 for update") at StorageConnection.cpp:430
430             if (connection)
(gdb) p connection
Cannot access memory at address 0x0
(gdb)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/24756

ChangeSet@1.2612, 2007-04-18 09:49:29+02:00, hakank@lu0011.wdf.sap.corp +6 -0
  Test for Bug#27767 is currently failing.
  
  Adjusted results file for Falcon's I_S tables.

Added test case falcon_bug_27767.test which is currently failing.

This fails because of the CREATE INDEX in connection 1.

After that in connection 2 
  StorageTableShare.pathName gets './db1/falcon_temporary.fts'

Falcon was creating the internal temp table in the temp table
database / tablespace, so the rename back to the original as
part of the table rebuild for add_index wasn't working.

Crash is gone but now data is missing:

hakan@lu0011:~/work/mysql/mysql-5.1-falcon/mysql-test$ ./mysql-test-run.pl --enable-disabled falcon_bug_27767Logging: ./mysql-test-run.pl --enable-disabled falcon_bug_27767
MySQL Version 6.0.0
Using binlog format 'mixed'
Skipping ndbcluster, mysqld not compiled with ndbcluster
Setting mysqld to support SSL connections
Binaries are debug compiled
Using MTR_BUILD_THREAD      = 0
Using MASTER_MYPORT         = 9306
Using MASTER_MYPORT1        = 9307
Using SLAVE_MYPORT          = 9308
Using SLAVE_MYPORT1         = 9309
Using SLAVE_MYPORT2         = 9310
Using IM_PORT               = 9312
Using IM_MYSQLD1_PORT       = 9313
Using IM_MYSQLD2_PORT       = 9314
Killing Possible Leftover Processes
Removing Stale Files
Creating Directories
Installing Master Database
Installing Master Database
=======================================================
Starting Tests in the 'main' suite

Test(s) which will be run though they are marked as disabled:
  falcon_bug_27767     : Bug#27767 2007-04-18 hakank Currently failing

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

falcon_bug_27767               [ fail ]

ERROR: Bug#27767 2007-04-18 hakank Currently failing
Below are the diffs between actual and expected results:
-------------------------------------------------------
*** r/falcon_bug_27767.result   2007-04-19 12:52:10.000000000 +0300
--- r/falcon_bug_27767.reject   2007-04-20 02:07:50.000000000 +0300
***************
*** 17,21 ****
  # Switch to connection default
  SELECT count(*) FROM t1;
  count(*)
! 1
  USE test;
--- 17,21 ----
  # Switch to connection default
  SELECT count(*) FROM t1;
  count(*)
! 0
  USE test;
-------------------------------------------------------
Please follow the instructions outlined at
http://www.mysql.com/doc/en/Reporting_mysqltest_bugs.html
to find the reason to this problem and how to report this.

Related to Bug#27895

Test passes now

falcon_bug_27767               [ pass ]            440
-------------------------------------------------------
Stopping All Servers
All 1 tests were successful.
The servers where restarted 1 times
Spent 0.44 seconds actually executing testcases

A note has been added to the 6.0.0 changelog.

A note has been added to the 6.0.0 changelog.