[MDEV-8408] Assertion `inited==INDEX' failed in int handler::ha_index_first(uchar*) Created: 2015-07-02  Updated: 2015-11-10  Resolved: 2015-11-10

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Replication
Affects Version/s: N/A
Fix Version/s: 10.0.22, 10.1.9

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-6877 Merge binlog_row_image from MySQL 5.6 Closed
Sprint: 10.1.9-2

 Description    

--source include/have_log_bin.inc
 
--source include/have_binlog_format_row.inc
 
--source include/have_innodb.inc
 
 
 
START TRANSACTION WITH CONSISTENT SNAPSHOT;
 
 
 
--connect (con1,localhost,root,,test)
 
CREATE TABLE IF NOT EXISTS t2 (pk INT PRIMARY KEY, i INT, KEY(i)) ENGINE=InnoDB;
 
 
 
--connection default
 
UPDATE t2 SET i = 0;
 

10.1/sql/handler.cc:2670: int handler::ha_index_first(uchar*): Assertion `inited==INDEX' failed.
 
150702  1:33:39 [ERROR] mysqld got signal 6 ;
 
 
 
#6  0x00007f1e45bc4311 in *__GI___assert_fail (assertion=0x7f1e48f3e999 "inited==INDEX", file=<optimized out>, line=2670, function=0x7f1e48f425a0 "int handler::ha_index_first(uchar*)") at assert.c:81
 
#7  0x00007f1e48773946 in handler::ha_index_first (this=0x7f1e3f4e1888, buf=0x7f1e3f4d1f88 "\377") at 10.1/sql/handler.cc:2670
 
#8  0x00007f1e48478968 in rr_index_first (info=0x7f1e47f5b270) at 10.1/sql/records.cc:383
 
#9  0x00007f1e48613b55 in mysql_update (thd=0x7f1e3c1ea070, table_list=0x7f1e3f52b160, fields=..., values=..., conds=0x0, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f1e47f5b618, updated_return=0x7f1e47f5b620) at 10.1/sql/sql_update.cc:624
 
#10 0x00007f1e4852fe0a in mysql_execute_command (thd=0x7f1e3c1ea070) at 10.1/sql/sql_parse.cc:3714
 
#11 0x00007f1e4853aea7 in mysql_parse (thd=0x7f1e3c1ea070, rawbuf=0x7f1e3f52b088 "UPDATE t2 SET i = 0", length=19, parser_state=0x7f1e47f5c1a0) at 10.1/sql/sql_parse.cc:7181
 
#12 0x00007f1e48529d9c in dispatch_command (command=COM_QUERY, thd=0x7f1e3c1ea070, packet=0x7f1e3c107071 "UPDATE t2 SET i = 0", packet_length=19) at 10.1/sql/sql_parse.cc:1470
 
#13 0x00007f1e48528abc in do_command (thd=0x7f1e3c1ea070) at 10.1/sql/sql_parse.cc:1093
 
#14 0x00007f1e4866a803 in do_handle_one_connection (thd_arg=0x7f1e3c1ea070) at 10.1/sql/sql_connect.cc:1350
 
#15 0x00007f1e4866a554 in handle_one_connection (arg=0x7f1e3c1ea070) at 10.1/sql/sql_connect.cc:1262
 
#16 0x00007f1e48bea2cf in pfs_spawn_thread (arg=0x7f1e3fbbfb70) at 10.1/storage/perfschema/pfs.cc:1860
 
#17 0x00007f1e47bdfb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#18 0x00007f1e45c7495d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Apparently it was introduced by the patch for MDEV-6877.

 Comments   
Comment by Michael Widenius [ 2015-10-23 ]

The crash was because a not handled error when choosing which index to use to traverse the logs.
The crash is both in 10.0 and 10.1, depending on what the optimiser decides to do.
In 10.1 the optimizer wrongly thinks that all keys are updated and because of this chooses an suboptimal plan, which causes the bug to appear.
I am fixing the crash in 10.0 and will in 10.1 fix the optimizer issue (wrong write bitmap)

This is not a critical issue as this error only happens when trying within a snapshot access a table that didn't exist or changed when the snapshot was created.

Comment by Michael Widenius [ 2015-11-10 ]

The crash was because errors from init_read_record_idx() was not taken care of.
The reason for getting the crash was that when one uses replication the query plan changes (it shouldn't) and it took a patch that was not properly tested.

In MariaDB 10.1 I also fixed that the query plan doesn't change for UPDATE if one is using replication. This will speed up some update queries not using primary key when replication is used.

Generated at Thu Feb 08 07:26:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.