MySQL Bugs: #27574: Falcon: crash if trigger and no autocommit

Bug #27574	Falcon: crash if trigger and no autocommit
Submitted:	1 Apr 2007 18:00	Modified:	20 Apr 2007 14: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.0 / 64-bit)
Assigned to:	Kevin Lewis	CPU Architecture:	Any

Description:
I create two Falcon tables.
I create a trigger on one table which refers to the other table.
I insert one row in each table.
I update the table which has the trigger.
I select from the table which has the trigger.
Crash.

Autocommit must be off; engine must be Falcon.

ChangeSet@1.2529, 2007-03-29

How to repeat:
mysql> create table t1 (s1 int) engine=falcon;
Query OK, 0 rows affected (0.21 sec)

mysql> create table t2 (s1 int) engine=falcon;
Query OK, 0 rows affected (0.00 sec)

mysql> create trigger t1_bu before update on t1 for each row update t2 set s1 =                                           2 where s1 = 1;
Query OK, 0 rows affected (0.00 sec)

mysql> set @@autocommit=0;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t2 values (0);
Query OK, 1 row affected (0.00 sec)

mysql> insert into t1 values (0);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> update t1 set s1 = -1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from t1;
ERROR 2013 (HY000): Lost connection to MySQL server during query

create table t1 (s1 int) engine=falcon;
create table t2 (s1 int) engine=falcon;
create trigger t1_bu before update on t1 for each row update t2 set s1 = 2 where s1 = 1;
set @@autocommit=0;
insert into t2 values (0);
insert into t1 values (0);
commit;
update t1 set s1 = -1;
select * from t1;

verified:

Version: '5.2.4-falcon-alpha-debug'  socket: '/tmp/mysql.sock'  port: 3306  yes
070402  9:10:41 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388572
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337592 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x8e07c98
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb55abbfc, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81f9275 handle_segfault + 541
0x838d927 _ZN11Transaction16releaseSavepointEi + 75
0x837b9fc _ZN15StorageDatabase16savepointReleaseEP10Connectioni + 32
0x837ac12 _ZN17StorageConnection16savepointReleaseEi + 34
0x837ae81 _ZN17StorageConnection11releaseVerbEv + 31
0x83785c5 _ZN15NfsStorageTable13external_lockEP3THDi + 141
0x82dff8c _ZN7handler16ha_external_lockEP3THDi + 174
0x81f31ff _Z15unlock_externalP3THDPP8st_tablej + 125
0x81f282d _Z24mysql_unlock_read_tablesP3THDP13st_mysql_lock + 267
0x825ed83 _ZN4JOIN9join_freeEv + 377
0x8266b43 _Z9do_selectP4JOINP4ListI4ItemEP8st_tableP9Procedure + 827
0x8256253 _ZN4JOIN4execEv + 7025
0x8256728 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_sel + 634
0x825162c _Z13handle_selectP3THDP6st_lexP13select_resultm + 332
0x820d02a _Z21execute_sqlcom_selectP3THDP13st_table_list + 750
0x8205c29 _Z21mysql_execute_commandP3THD + 1595
0x820e8e1 _Z11mysql_parseP3THDPcj + 299
0x8203f31 _Z16dispatch_command19enum_server_commandP3THDPcj + 2073
0x820370c _Z10do_commandP3THD + 612
0x82022d5 handle_one_connection + 253
0xb7daaaa7 _end + -1352864457
0xb7e75c2e _end + -1352032578
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8e19b38 = select * from t1
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

I have found this problem and am pushing a fix.

I made a change to be sure that Transaction::recordPtr is set to the correct thing, which is that place where the next RecordVersion will be attached to the transaction. Transaction::RemoveRecord was handling this incorrectly. Also, I added code to make Transaction::removeRecord adjust any SavePoint::records pointer if it is pointing into the RecordVersion being removed.

Fixed:

[23:16] root@test>set sql_mode='';
Query OK, 0 rows affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>create table t1 (s1 int) engine=falcon;
Query OK, 0 rows affected (0.37 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>create table t2 (s1 int) engine=falcon;
Query OK, 0 rows affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>create trigger t1_bu before update on t1 for each row update t2 set s1 = 2 where
s1 = 1;
Query OK, 0 rows affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>set @@autocommit=0;
Query OK, 0 rows affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>insert into t2 values (0);
Query OK, 1 row affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>insert into t1 values (0);
Query OK, 1 row affected (0.00 sec)

6.0.0-falcon-alpha-debug
[23:16] root@test>commit;
Query OK, 0 rows affected (0.01 sec)

6.0.0-falcon-alpha-debug
[23:17] root@test>update t1 set s1 = -1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

6.0.0-falcon-alpha-debug
[23:17] root@test>select * from t1;
+------+
| s1   |
+------+
|   -1 |
+------+
1 row in set (0.00 sec)

6.0.0-falcon-alpha-debug

Test is falcon_bug_27574.test

A note has been added to the 5.2.4 changelog.

This bug report entry has been moved to the 6.0.0 Falcon changelog.