assert on SAVEPOINT without transaction

Bug #534806 reported by Eric Day on 2010-03-09
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Critical
Jay Pipes

Bug Description

During randgen, the follow assert is hit:

(gdb) bt
#0 0x00007f6859c494b5 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007f6859c4cf50 in *__GI_abort () at abort.c:92
#2 0x00007f6859c42481 in *__GI___assert_fail (
    assertion=0x8660c3 "trx->conc_state != 0", file=<value optimized out>,
    line=2385,
    function=0x869700 "virtual int InnobaseEngine::doSetSavepoint(drizzled::Session*, drizzled::NamedSavepoint&)") at assert.c:81
#3 0x000000000068ee0c in InnobaseEngine::doSetSavepoint (
    this=<value optimized out>, session=<value optimized out>,
    named_savepoint=...) at plugin/innobase/handler/ha_innodb.cc:2385
#4 0x000000000065a9f0 in drizzled::plugin::TransactionalStorageEngine::setSavepoint (this=<value optimized out>, session=0x2b8b4c0, sv=...)
    at ./drizzled/plugin/transactional_storage_engine.h:93
#5 drizzled::TransactionServices::ha_savepoint (this=<value optimized out>,
    session=0x2b8b4c0, sv=...) at drizzled/transaction_services.cc:917
#6 0x000000000064092c in drizzled::statement::Savepoint::execute (
    this=0x2ccc5f0) at drizzled/statement/savepoint.cc:74
#7 0x00000000006054c4 in mysql_execute_command (session=0x2b8b4c0)
    at drizzled/sql_parse.cc:473
#8 0x0000000000606c45 in drizzled::mysql_parse (session=0x2b8b4c0,
    inBuf=0x2b239f8 "SAVEPOINT A", length=11) at drizzled/sql_parse.cc:728
#9 0x00000000006070cd in drizzled::dispatch_command (
    command=<value optimized out>, session=0x2b8b4c0,
    packet=0x2c9e091 "SAVEPOINT A", packet_length=11)
    at drizzled/sql_parse.cc:216
#10 0x00000000005da54f in drizzled::Session::executeStatement (this=0x2b8b4c0)
    at drizzled/session.cc:736
#11 0x00000000005dbe32 in drizzled::Session::run (this=0x2b8b4c0)
    at drizzled/session.cc:592
#12 0x00007f6847392352 in MultiThreadScheduler::runSession (
    arg=<value optimized out>) at ./plugin/multi_thread/multi_thread.h:67
#13 session_thread (arg=<value optimized out>)
    at plugin/multi_thread/multi_thread.cc:43
#14 0x00007f6859f8ba04 in start_thread (arg=<value optimized out>)
    at pthread_create.c:300

The query is simply "SAVEPOINT A", but innodb asserts because there is not an active transaction. The 'trx' structure does not seem to be corrupt:

(gdb) frame 3
#3 0x000000000068ee0c in InnobaseEngine::doSetSavepoint (
    this=<value optimized out>, session=<value optimized out>,
    named_savepoint=...) at plugin/innobase/handler/ha_innodb.cc:2385
2385 assert(trx->conc_state != TRX_NOT_STARTED);
(gdb) print *trx
$5 = {magic_n = 91118598, op_info = 0x7de6a7 "", is_purge = 0,
  is_recovered = 0, conc_state = 0, que_state = 0, isolation_level = 2,
  check_foreigns = 1, check_unique_secondary = 1, support_xa = 1,
  flush_log_later = 0, must_flush_log_later = 0, dict_operation = 0,
  duplicates = 0, has_search_latch = 0, declared_to_be_inside_innodb = 0,
  handling_signals = 0, dict_operation_lock_mode = 0, start_time = 1268093823,
  id = {high = 0, low = 15140}, xid = {formatID = -1, gtrid_length = 0,
    bqual_length = 0, data = '\000' <repeats 127 times>}, no = {high = 0,
    low = 15141}, commit_lsn = 3664332, table_id = {high = 0, low = 0},
  mysql_thd = 0x2b8b4c0, mysql_query_str = 0x0, mysql_log_file_name = 0x0,
  mysql_log_offset = 0, mysql_thread_id = 140085757466896,
  mysql_process_no = 3424, mysql_n_tables_locked = 0,
  search_latch_timeout = 10000, n_tickets_to_enter_innodb = 0, trx_list = {
    prev = 0x0, next = 0x2b55530}, mysql_trx_list = {prev = 0x0,
    next = 0x2b55530}, error_state = 10, error_info = 0x2d21d80,
  error_key_num = 0, sess = 0x29c44b0, graph = 0x0, n_active_thrs = 0,
  graph_before_signal_handling = 0x0, sig = {type = 0, sender = 0,
    receiver = 0x0, savept = {least_undo_no = {high = 0, low = 0}}, signals = {
      prev = 0x0, next = 0x0}, reply_signals = {prev = 0x0, next = 0x0}},
  signals = {count = 0, start = 0x0, end = 0x0}, reply_signals = {count = 0,
    start = 0x0, end = 0x0}, wait_lock = 0x0,
  was_chosen_as_deadlock_victim = 0, wait_started = 1268093823, wait_thrs = {
    count = 0, start = 0x0, end = 0x0}, deadlock_mark = 1,
  lock_heap = 0x7f6834052bc0, trx_locks = {count = 0, start = 0x0, end = 0x0},
  global_read_view_heap = 0x7f683401bcb0, global_read_view = 0x0,
  read_view = 0x0, trx_savepoints = {count = 0, start = 0x0, end = 0x0},
  undo_mutex = {event = 0x7f6834053640, lock_word = 0 '\000', waiters = 0,
    list = {prev = 0x0, next = 0x2b557b8},
    cfile_name = 0x880c34 "plugin/innobase/trx/trx0trx.c", cline = 130,
    count_os_wait = 0}, undo_no = {high = 0, low = 0}, last_sql_stat_start = {
    least_undo_no = {high = 0, low = 0}}, rseg = 0x0, insert_undo = 0x0,
  update_undo = 0x0, roll_limit = {high = 0, low = 0}, pages_undone = 0,
  undo_no_arr = 0x7f6834400a50, n_autoinc_rows = 0,
  autoinc_locks = 0x7f6834054250,
  detailed_error = "\000r\002\064h\177\000\000\260\374\021\064h\177\000\000 \245\003\064h\177\000\000\000\301\001\064h\177\000\000\000\070\005\064h\177\000\000\300\320\027\064h\177\000\000 \303\001\064h\177\000\000`\032\001\064h\177\000\000\340=\026\064h\177\000\000\260\325\027\064h\177\000\000@U\000\064h\177\000\000 V\000\064h\177\000\000\000W\000\064h\177\000\000\220\377\021\064h\177\000\000p\000\022\064h\177\000\000P\001\022\064h\177\000\000 RN4h\177\000\000\000SN4h\177\000\000\060TN4h\177\000\000`UN4h\177\000\000\220VN4h\177\000\000PaN4h\177\000\000\020\004\000\000\000\000\000\000T\000\000\000\000\000\000\000\360\r@4h\177", '\000' <repeats 14 times>, "h\177\000\000\060\261\265\000\000\000\000\000"...}

Related branches

Jay Pipes (jaypipes) on 2010-03-09
Changed in drizzle:
importance: Undecided → Critical
status: New → Confirmed
assignee: nobody → Jay Pipes (jaypipes)
milestone: none → 2010-03-15
Jay Pipes (jaypipes) on 2010-03-10
Changed in drizzle:
status: Confirmed → In Progress
Jay Pipes (jaypipes) wrote :

After much ado, Eric and I have narrowed this down to a reproduceable test case. Yeah! \o/. It turns out that AUTOCOMMIT=0 and LIMIT 0 together are the culprit, and the following test case will hit always assert:

SET AUTOCOMMIT = 0;
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY);
COMMIT;
UPDATE t1 SET id = 2 WHERE id != 2 LIMIT 0;
SAVEPOINT A;

Jay Pipes (jaypipes) on 2010-03-10
Changed in drizzle:
status: In Progress → Fix Committed
Jay Pipes (jaypipes) on 2010-03-12
Changed in drizzle:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers