assert on SAVEPOINT without transaction

Bug #534806 reported by Eric Day
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Fix Released
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)
Changed in drizzle:
importance: Undecided → Critical
status: New → Confirmed
assignee: nobody → Jay Pipes (jaypipes)
milestone: none → 2010-03-15
Jay Pipes (jaypipes)
Changed in drizzle:
status: Confirmed → In Progress
Revision history for this message
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)
Changed in drizzle:
status: In Progress → Fix Committed
Jay Pipes (jaypipes)
Changed in drizzle:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.