MySQL Bugs: #40274: Falcon assertion in Transaction::releaseDependencies at Transaction.cpp:792

Bug #40274	Falcon assertion in Transaction::releaseDependencies at Transaction.cpp:792
Submitted:	23 Oct 2008 4:37	Modified:	15 May 2009 12:50
Reporter:	Alexey Stroganov	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S1 (Critical)
Version:	6.0.8pre, 6.0-falcon-team	OS:	Any
Assigned to:	Olav Sandstå	CPU Architecture:	Any
Tags:	F_TRANSACTION

Description:
Got following assertion while testing of the recent 6.0.8pre with sysbench:

[Falcon] Error: assertion (dependencies == 0) failed at line 104 in file Transaction.cpp

081023  1:07:47 - mysqld got signal 6 ;

key_buffer_size=8388600
read_buffer_size=131072
max_used_connections=128
max_threads=1600
thread_count=128
connection_count=128
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 324674 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x2aaae4a1c890
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...
stack_bottom = 0x407af190 thread_stack 0x20000
/data0/ranger/mysql-6.0.8-alpha-pb130-linux-x86_64/bin/mysqld(my_print_stacktrace+0x2e)[0xb6a14e]
[Falcon] Error: assertion (transaction->state != Initializing) failed at line 792 in file Transaction.cpp

I got 5 core files for different queries, backtrace for one of them:

bt:

#0  0x00002b7ad6b6afed in raise () from /lib64/libpthread.so.0
#1  0x00000000008ea2e2 in Error::error (string=<value optimized out>) at Error.cpp:94
#2  0x00000000008bba74 in Transaction::commitNoUpdates (this=0x2aaae27a1bb8) at Transaction.cpp:792
#3  0x00000000008bbfcc in Transaction::commit (this=0x2aaae27a1bb8) at Transaction.cpp:246
#4  0x00000000008d2066 in Connection::commit (this=0x2aaaab513028) at Connection.cpp:272
#5  0x000000000089be3b in StorageConnection::commit (this=0x2aaaab512f98) at StorageConnection.cpp:146
#6  0x0000000000898395 in StorageInterface::external_lock (this=0x2aaae542d878, thd=0x1b5c2e0, lock_type=2)
    at ha_falcon.cpp:1934
#7  0x000000000077b33a in handler::ha_external_lock (this=0x404e, thd=0x40f0, lock_type=6) at handler.cc:5298
#8  0x000000000067ea44 in mysql_unlock_tables (thd=0x1b5c2e0, sql_lock=0x2aaae4f25270) at lock.cc:800
#9  0x00000000006707eb in select_send::send_eof (this=0x1bd99f0) at sql_class.cc:1655
#10 0x00000000006f3398 in do_select (join=0x1bbce18, fields=<value optimized out>, table=0x0, procedure=0x0)
    at sql_select.cc:13497
#11 0x000000000070ac55 in JOIN::exec (this=0x1bbce18) at sql_select.cc:2829
#12 0x000000000070c840 in mysql_select (thd=0x1b5c2e0, rref_pointer_array=0x1bd8110, tables=0x1bd8bd8, wild_num=0,
    fields=@0x1bd8030, conds=0x1bd9878, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0,
    select_options=2416200192, result=0x1bd99f0, unit=0x1bd7ac8, select_lex=0x1bd7f28) at sql_select.cc:3019
#13 0x000000000070d219 in handle_select (thd=0x1b5c2e0, lex=0x1bd7a28, result=0x1bd99f0, setup_tables_done_option=0)
    at sql_select.cc:301
#14 0x0000000000690c99 in execute_sqlcom_select (thd=0x1b5c2e0, all_tables=0x1bd8bd8) at sql_parse.cc:4644
#15 0x0000000000695ead in mysql_execute_command (thd=0x1b5c2e0) at sql_parse.cc:2064
#16 0x0000000000717ff8 in Prepared_statement::execute (this=0x1bccb50, expanded_query=<value optimized out>,
    open_cursor=false) at sql_prepare.cc:3577
#17 0x000000000071a440 in Prepared_statement::execute_loop (this=0x1bccb50, expanded_query=0x4034c3d0, open_cursor=false,
    packet=<value optimized out>, packet_end=<value optimized out>) at sql_prepare.cc:3244
#18 0x000000000071a7dd in mysql_stmt_execute (thd=0x1b5c2e0, packet_arg=0x1bb4d61 "", packet_length=15)
    at sql_prepare.cc:2465
#19 0x000000000069a59d in dispatch_command (command=COM_STMT_EXECUTE, thd=0x1b5c2e0, packet=0x1bb4d61 "", packet_length=15)
    at sql_parse.cc:960
#20 0x000000000069aa86 in do_command (thd=0x1b5c2e0) at sql_parse.cc:689
#21 0x000000000068def4 in handle_one_connection (arg=0x1b5c2e0) at sql_connect.cc:1156
#22 0x00002b7ad6b64193 in start_thread () from /lib64/libpthread.so.0
#23 0x00002b7ad719745d in clone () from /lib64/libc.so.6
#24 0x0000000000000000 in ?? ()

How to repeat:
This assertion happens randomly. Will provide details details how to repeat shortly. In meantime cores file are accessible.

This is the same bug as in bug #38739 "Assert in Transaction::initialize during simple SELECT quries". The difference is just that a different thread hits the "same" assert but in a different place in the code.

Olav, there are two asserts mentioned here;
  Transaction.cpp, line 104,  AASSERT(dependencies == 0);
  Transaction.cpp, line 792,  ASSERT(transaction->state != Initializing);
Both of these will not happen with the new dependency mechanism you are working on.

This was a bug in Falcon's old dependency manager. This has now been replaced by a new dependency manager. The code for this is committed as part of WL#4654.

The code for the new dependency manager is now merged into mysql-6.0 and will be included in 6.0.10-alpha.

A note has been added to the 6.0.10 changelog: 

The internal dependency mechanism for handling records and transactions within Falcon has been updated. This fixes a number of issues with transactions and concurrent workloads within Falcon tables.