Bug #39444 Maria endless loop in lfind on commit
Submitted: 14 Sep 2008 20:04 Modified: 4 Jul 2013 13:22
Reporter: Philip Stoev Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Server: Maria storage engine Severity:S1 (Critical)
Version:6.0.7 OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[14 Sep 2008 20:04] Philip Stoev
Description:
When running the rpl_sys SystemQA test with statement-based logging, Maria deadlocked with one thread doing an endless loop and the other threads waiting. The backtrace is as follows:

#0  lfind (head=0x1966aaf8, cs=0xf5b400, hashnr=1594105287, key=0x2aaab0003950 "\020©\001", keylen=<value optimized out>, cursor=0x4bed2e70, pins=0x19675780)
    at lf_hash.c:97
#1  0x0000000000a7a3ff in lf_hash_insert (hash=0x11cc860, pins=0x19675780, data=<value optimized out>) at lf_hash.c:160
#2  0x00000000009fbfb6 in trnman_end_trn (trn=0x2aaab0003900, commit=1 '\001') at trnman.c:437
#3  0x0000000000a681c4 in ma_commit (trn=0x2aaab0003900) at ma_commit.c:60
#4  0x0000000000a0eb66 in ha_maria::external_lock (this=0x19721908, thd=0x1968f040, lock_type=2) at ha_maria.cc:2265
#5  0x000000000073264a in handler::ha_external_lock (this=0x0, thd=0x19696a30, lock_type=426338864) at handler.cc:5220
#6  0x000000000063d968 in mysql_unlock_tables (thd=0x1968f040, sql_lock=0x2aaab4005400) at lock.cc:799
#7  0x000000000068bba7 in close_thread_tables (thd=0x1968f040, skip_mdl=false) at sql_base.cc:1424
#8  0x00000000007a2291 in sp_lex_keeper::reset_lex_and_exec_core (this=0x19823668, thd=0x1968f040, nextp=0x4bed3328, open_tables=<value optimized out>,
    instr=0x19823628) at sp_head.cc:2729
#9  0x00000000007a2e34 in sp_instr_stmt::execute (this=0x19823628, thd=0x1968f040, nextp=0x4bed3328) at sp_head.cc:2834
#10 0x00000000007a05b2 in sp_head::execute (this=0x197f88a8, thd=0x1968f040) at sp_head.cc:1238
#11 0x00000000007a0c8b in sp_head::execute_procedure (this=0x197f88a8, thd=0x1968f040, args=0x19691448) at sp_head.cc:1969
#12 0x00000000006571a4 in mysql_execute_command (thd=0x1968f040) at sql_parse.cc:4303
#13 0x0000000000659e5f in mysql_parse (thd=0x1968f040, inBuf=0x19691a38 "CALL test.insdel1()", length=19, found_semicolon=0x4bed50a0) at sql_parse.cc:5932
#14 0x000000000065a9de in dispatch_command (command=COM_QUERY, thd=0x1968f040, packet=0x197f4881 "CALL test.insdel1()", packet_length=<value optimized out>)
    at sql_parse.cc:1134
#15 0x000000000064dee2 in handle_one_connection (arg=<value optimized out>) at sql_connect.cc:1153
#16 0x0000003ba88062f7 in start_thread () from /lib64/libpthread.so.0
#17 0x0000003ba80ce85d in clone () from /lib64/libc.so.6

The loop is this:

97          } while (link != cursor->curr->link && LF_BACKOFF);
101         if (*cursor->prev != (intptr)cursor->curr)
98          cur_hashnr= cursor->curr->hashnr;
99          cur_key= cursor->curr->key;
100         cur_keylen= cursor->curr->keylen;
101         if (*cursor->prev != (intptr)cursor->curr)
106         if (!DELETED(link))
108           if (cur_hashnr >= hashnr)
116           cursor->prev= &(cursor->curr->link);
211     make_atomic_store(ptr)
134         cursor->curr= cursor->next;
211     make_atomic_store(ptr)
90          if (unlikely(!cursor->curr))
94            link= cursor->curr->link;
95            cursor->next= PTR(link);
211     make_atomic_store(ptr)
97          } while (link != cursor->curr->link && LF_BACKOFF);

How to repeat:
If this happens again, a test case will be provided.
[10 Mar 2009 21:06] Guilhem Bichot
does this happen again?
[13 Mar 2009 10:41] Philip Stoev
This bug is very old and happened only once. I will re-open it if it happens again.
[4 Jul 2013 13:22] Dmitry Lenev
Hello!

It was decided that is not feasible to fix this bug. Therefore I am closing it as "Won't fix".