Description:
During work on bug #35932 I have several times observed that Falcon crashes on the following assert:
ASSERT(dependencies == 0);
in Transaction::initialize().
The crash occurred when running 30 clients each repeatedly running SELECT statements for a "random" record from a single table.
The call stack.
[1] __lwp_kill(0x38, 0x6), at 0xfec24aa7
[2] _thr_kill(0x38, 0x6), at 0xfec22250
=>[3] my_write_core(sig = 6), line 307 in "stacktrace.c"
[4] handle_segfault(sig = 6), line 2657 in "mysqld.cc"
[5] __sighndlr(0x6, 0x0, 0xfd3f22c0, 0x83764e0), at 0xfec23e6f
[6] call_user_handler(0x6, 0x0, 0xfd3f22c0), at 0xfec1a30e
[7] sigacthandler(0x6, 0x0, 0xfd3f22c0, 0xf, 0x0, 0x807007), at 0xfec1a48e
---- called from signal handler with signal 6 (SIGABRT) ------
[8] __lwp_kill(0x38, 0x6), at 0xfec24aa7
[9] raise(0x6, 0x0), at 0xfebd1217
[10] Error::debugBreak(), line 94 in "Error.cpp"
[11] Error::error(string = 0x8b35ba6 "assertion (%s) failed at line %d in file %s\n", ...), line 71 in "Error.cpp"
[12] Error::assertionFailed(text = 0x8b3bc72 "dependencies == 0", fileName = 0x8b3bc84 "Transaction.cpp", line = 107), line 78 in "Error.cpp"
[13] Transaction::initialize(this = 0x91153c0, cnct = 0x90df220, seq = 34927159U), line 107 in "Transaction.cpp"
[14] TransactionManager::startTransaction(this = 0x90c9880, connection = 0x90df220), line 123 in "TransactionManager.cpp"
[15] Database::startTransaction(this = 0x8ec28a8, connection = 0x90df220), line 1236 in "Database.cpp"
[16] Connection::getTransaction(this = 0x90df220), line 256 in "Connection.cpp"
[17] StorageDatabase::savepointSet(this = 0x90c1ea8, connection = 0x90df220), line 509 in "StorageDatabase.cpp"
[18] StorageConnection::savepointSet(this = 0x90c8a28), line 203 in "StorageConnection.cpp"
[19] StorageConnection::markVerb(this = 0x90c8a28), line 334 in "StorageConnection.cpp"
[20] StorageInterface::external_lock(this = 0x3575d9b8, thd = 0x2e99b900, lock_type = 1), line 1912 in "ha_falcon.cpp"
[21] handler::ha_external_lock(this = 0x3575d9b8, thd = 0x2e99b900, lock_type = 1), line 5273 in "handler.cc"
[22] lock_external(thd = 0x2e99b900, tables = 0x8e9fa30, count = 1U), line 389 in "lock.cc"
[23] mysql_lock_tables(thd = 0x2e99b900, tables = 0x2ebdd4f0, count = 1U, flags = 0, need_reopen = 0xfd3f293b), line 290 in "lock.cc"
[24] lock_tables(thd = 0x2e99b900, tables = 0x2ebdce60, count = 1U, flags = 0, need_reopen = 0xfd3f293b), line 4407 in "sql_base.cc"
[25] open_and_lock_tables_derived(thd = 0x2e99b900, tables = 0x2ebdce60, derived = true, flags = 0), line 4112 in "sql_base.cc"
[26] open_and_lock_tables(thd = 0x2e99b900, tables = 0x2ebdce60), line 1613 in "mysql_priv.h"
[27] execute_sqlcom_select(thd = 0x2e99b900, all_tables = 0x2ebdce60), line 4810 in "sql_parse.cc"
[28] mysql_execute_command(thd = 0x2e99b900), line 2022 in "sql_parse.cc"
[29] mysql_parse(thd = 0x2e99b900, inBuf = 0x2ebdcce0 "SELECT data_fld FROM simple WHERE id = 64287", length = 44U, found_semicolon = 0xfd3f4d4c), line 5809 in "sql_parse.cc"
[30] dispatch_command(command = COM_QUERY, thd = 0x2e99b900, packet = 0x2ebe0029 "SELECT data_fld FROM simple WHERE id = 64287", packet_length = 44U), line 1050 in "sql_parse.cc"
[31] do_command(thd = 0x2e99b900), line 723 in "sql_parse.cc"
[32] handle_one_connection(arg = 0x2e99b900), line 1153 in "sql_connect.cc"
[33] _thr_setup(0xfd5e5a00), at 0xfec23a81
[34] _lwp_start(0x38, 0x6, 0x97000, 0xfd3f21cc, 0x8a5b092, 0x38), at 0xfec23d70
Not that the crash occurs with an instrumented (read printfified) version of Falcon so line numbers in the call stack are likely not the same as the checked in version. This extra instrumentation might also influence timing.
How to repeat:
I use the same client as I use for reproducing bug #35932. This client run with 30 concurrent client threads that all do single select statement for a "random" record from a single table.
