Bug #43491 Server crashes with Maria on delete with index-merge access
Submitted: 9 Mar 2009 8:23 Modified: 26 May 2010 17:52
Reporter: Nidhi Shrotriya Email Updates:
Status: Unsupported Impact on me:
None 
Category:MySQL Server: Maria storage engine Severity:S3 (Non-critical)
Version:6.0.11 OS:Linux
Assigned to: CPU Architecture:Any

[9 Mar 2009 8:23] Nidhi Shrotriya
Description:
See How to Repeat section.

How to repeat:
SHOW CREATE TABLE t2;
Table   Create Table
t2      CREATE TABLE `t2` (
  `c1` tinyint(4) NOT NULL,
  `c2` tinyint(3) unsigned DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  KEY `c2` (`c2`),
  KEY `c1` (`c1`)
) ENGINE=MARIA DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1

INSERT INTO t2 VALUES(-128,0,1),(-1,1,1),(-2,2,2),(-3,3,3),(-4,4,4),(-5,5,5),(-6,6,6),(0,0,7),(1,1,8),(127,255,9);

SELECT * FROM t2 WHERE c1=127 OR c2=3 ORDER BY c1;
c1      c2      c3
-3      3       3
127     255     9

DELETE FROM t2 WHERE c1=127 OR c2=3 ORDER BY c1 LIMIT 2;

crashes at the above command with backtrace as below:

Thread 1 (process 17514):
#0  0xb7f36430 in __kernel_vsyscall ()
#1  0xb7edc158 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x08998eca in my_write_core (sig=6) at stacktrace.c:309
#3  0x0835215f in handle_segfault (sig=6) at mysqld.cc:2689
#4  <signal handler called>
#5  0xb7f36430 in __kernel_vsyscall ()
#6  0xb7c2f880 in raise () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7c31248 in abort () from /lib/tls/i686/cmov/libc.so.6
#8  0xb7c2872e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#9  0x08854c02 in ha_maria::index_first (this=0x9c4fa80, buf=0x9c4fc08 "�") at ha_maria.cc:1917
#10 0x08497ac4 in rr_index_first (info=0x9e207950) at records.cc:354
#11 0x08425512 in mysql_delete (thd=0x9b66060, table_list=0x9c02ac8, conds=0x9c032f0, order=0x9b67484, limit=2, options=0, reset_auto_increment=false) at sql_delete.cc:296
#12 0x08368638 in mysql_execute_command (thd=0x9b66060) at sql_parse.cc:3253
#13 0x0836dde8 in mysql_parse (thd=0x9b66060, inBuf=0x9c027b8 "DELETE FROM t2 WHERE c1=127 OR c2=3 ORDER BY c1 LIMIT 2", length=55, found_semicolon=0x9e208be8)
    at sql_parse.cc:5752
#14 0x0836e96a in dispatch_command (command=COM_QUERY, thd=0x9b66060, packet=0x9c1f041 "DELETE FROM t2 WHERE c1=127 OR c2=3 ORDER BY c1 LIMIT 2", packet_length=55)
    at sql_parse.cc:1009
#15 0x0836ff45 in do_command (thd=0x9b66060) at sql_parse.cc:691
#16 0x0835bfd3 in handle_one_connection (arg=0x9b66060) at sql_connect.cc:1146
#17 0xb7ed750f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#18 0xb7ce57ee in clone () from /lib/tls/i686/cmov/libc.so.6
[9 Mar 2009 12:44] MySQL Verification Team
Thank you for the bug report. Verified as described.

000000007798420A    ntdll.dll!_wcsupr()
0000000077984124    ntdll.dll!_wcsupr()
00000001402A340F    mysqld.exe!my_rw_rdlock()[thr_rwlock.c:89]
000000014051F5A9    mysqld.exe!maria_rnext()[ma_rnext.c:48]
00000001404EE3B0    mysqld.exe!ha_maria::index_first()[ha_maria.cc:1961]
00000001400F46FE    mysqld.exe!rr_index_first()[records.cc:354]
0000000140151220    mysqld.exe!mysql_delete()[sql_delete.cc:297]
000000014017619F    mysqld.exe!mysql_execute_command()[sql_parse.cc:3253]
0000000140179028    mysqld.exe!mysql_parse()[sql_parse.cc:5757]
0000000140179A6A    mysqld.exe!dispatch_command()[sql_parse.cc:1011]
000000014017A89C    mysqld.exe!do_command()[sql_parse.cc:691]
0000000140219101    mysqld.exe!handle_one_connection()[sql_connect.cc:1146]
00000001402A6C9E    mysqld.exe!pthread_start()[my_winthread.c:63]
000000014056A387    mysqld.exe!_callthreadstartex()[threadex.c:348]
000000014056A45F    mysqld.exe!_threadstartex()[threadex.c:326]
000000007783C3BD    kernel32.dll!BaseThreadInitThunk()
0000000077984581    ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
[12 Mar 2009 9:09] Guilhem Bichot
stil true
[13 Mar 2009 11:47] Christoffer Hall
The test can be simplified quite a bit.

CREATE TABLE `t2` (
  `c1` tinyint(4) NOT NULL,
  `c2` tinyint(3) unsigned DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  KEY `c2` (`c2`),
  KEY `c1` (`c1`)
) ENGINE=MARIA;

INSERT INTO t2 VALUES(-128,0,1),(-1,1,1),(-2,2,2),(-3,3,3),(-4,4,4),(-5,5,5),(-6,6,6),(0,0,7),(1,1,8),(127,255,9);
DELETE FROM t2 WHERE c1=127 OR c2=3 ORDER BY c1 LIMIT 2;

If any one of the two indexes are removed the problem goes away. 

The problem exposes itself in ha_maria::index_first. There is an assertion:
DBUG_ASSERT(inited == INDEX);

The variable inited is not INDEX but RND. The assertion checks for call order, which must somehow be violated. From the trace it seems an index merge happens.