Bug #38739 Assert in Transaction::initialize during simple SELECT queries
Submitted: 12 Aug 2008 7:25 Modified: 9 Jan 2009 13:58
Reporter: Olav Sandstå Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Falcon storage engine Severity:S3 (Non-critical)
Version:6.0.6 OS:Solaris (Solaris 10 on x64)
Assigned to: Olav Sandstå CPU Architecture:Any
Tags: F_TRANSACTION

[12 Aug 2008 7:25] Olav Sandstå
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.
[24 Oct 2008 10:20] Bugs System
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/56988

2880 Olav Sandstaa	2008-10-24
      Fix for Bug #38739 Assert in Transaction::initialize during simple
      SELECT queries
      
      Fixes an A-B-A problem in TransactionManager::startTransaction() where
      it was possible that the transaction object could be reused by another
      thread between the test for being available for reuse and actually
      being allocated.
[28 Oct 2008 8:10] Bugs System
Pushed into 6.0.8-alpha  (revid:olav@sun.com-20081024102010-i35auh1mgig8m31j) (version source revid:alik@mysql.com-20081027140343-anwg01vprlohj34t) (pib:5)
[9 Jan 2009 13:58] MC Brown
A note has been added to the 6.0.8 changelog: 

Running multiple SELECT operations on the same Falcon table could lead to an assertion within the Transaction::initialize. The same operation could also lead to a deadlock situation on the specified table.