[MDEV-7055] MySQL#74664 - InnoDB: Failing assertion: len <= col->len || col->mtype == 5 || (col->len == 0 && col->mtype == 1) in file rem0rec.cc line 845 Created: 2014-11-09  Updated: 2018-01-01  Resolved: 2018-01-01

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 5.5, 10.0
Fix Version/s: 5.5.42, 10.0.17, 10.1.4

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: upstream

Issue Links:
Relates
relates to MDEV-7057 Track most important upstream bugs wh... Closed
Sprint: 5.5.47-1

 Description   

Initially reported by Ramesh Sivaraman as http://bugs.mysql.com/bug.php?id=74664, refiling to make it searchable in Jira and to preserve the test case. 

DROP DATABASE test;CREATE DATABASE test;USE test;
 
set character_set_connection=ucs2;
 
create TABLE t1 select if(0=0,'Y','N');
 
insert INTO t1 values(date_format('2001-01-01','%W'));
 

InnoDB: Assertion failure in thread 140670201579264 in file rem0rec.cc line 845
 
InnoDB: Failing assertion: len <= col->len || col->mtype == 5 || (col->len == 0 && col->mtype == 1)
 
InnoDB: We intentionally generate a memory trap.
 

#5  0x00007ff0536d97c0 in *__GI_abort () at abort.c:92
 
#6  0x0000000000ac9361 in rec_get_converted_size_comp_prefix_low (index=0x7ff040014ff8, fields=0x7ff0400148b0, n_fields=4, extra=0x0, temp=false) at 10.0/storage/xtradb/rem/rem0rec.cc:844
 
#7  0x0000000000ac9791 in rec_get_converted_size_comp (index=0x7ff040014ff8, status=0, fields=0x7ff0400148b0, n_fields=4, extra=0x0) at 10.0/storage/xtradb/rem/rem0rec.cc:956
 
#8  0x0000000000bad59f in rec_get_converted_size (index=0x7ff040014ff8, dtuple=0x7ff040014878, n_ext=0) at 10.0/storage/xtradb/include/rem0rec.ic:1606
 
#9  0x0000000000bb298b in btr_cur_optimistic_insert (flags=0, cursor=0x7ff055651f70, offsets=0x7ff0556524e0, heap=0x7ff0556524d0, entry=0x7ff040014878, rec=0x7ff0556524c8, big_rec=0x7ff0556524d8, n_ext=0, thr=0x7ff0400bf738, mtr=0x7ff055651ff0) at 10.0/storage/xtradb/btr/btr0cur.cc:1392
 
#10 0x0000000000ae7918 in row_ins_clust_index_entry_low (flags=0, mode=2, index=0x7ff040014ff8, n_uniq=0, entry=0x7ff040014878, n_ext=0, thr=0x7ff0400bf738) at 10.0/storage/xtradb/row/row0ins.cc:2503
 
#11 0x0000000000ae8813 in row_ins_clust_index_entry (index=0x7ff040014ff8, entry=0x7ff040014878, thr=0x7ff0400bf738, n_ext=0) at 10.0/storage/xtradb/row/row0ins.cc:2909
 
#12 0x0000000000ae8b24 in row_ins_index_entry (index=0x7ff040014ff8, entry=0x7ff040014878, thr=0x7ff0400bf738) at 10.0/storage/xtradb/row/row0ins.cc:3007
 
#13 0x0000000000ae8de7 in row_ins_index_entry_step (node=0x7ff0400bf518, thr=0x7ff0400bf738) at 10.0/storage/xtradb/row/row0ins.cc:3084
 
#14 0x0000000000ae90fb in row_ins (node=0x7ff0400bf518, thr=0x7ff0400bf738) at 10.0/storage/xtradb/row/row0ins.cc:3224
 
#15 0x0000000000ae9460 in row_ins_step (thr=0x7ff0400bf738) at 10.0/storage/xtradb/row/row0ins.cc:3349
 
#16 0x0000000000affa54 in row_insert_for_mysql (mysql_rec=0x7ff040028e88 "\004", prebuilt=0x7ff0400bf078) at 10.0/storage/xtradb/row/row0mysql.cc:1314
 
#17 0x0000000000a09bbe in ha_innobase::write_row (this=0x7ff040229088, record=0x7ff040028e88 "\004") at 10.0/storage/xtradb/handler/ha_innodb.cc:7577
 
#18 0x0000000000874a2e in handler::ha_write_row (this=0x7ff040229088, buf=0x7ff040028e88 "\004") at 10.0/sql/handler.cc:5961
 
#19 0x000000000065fdf6 in write_record (thd=0x7ff04d30b070, table=0x7ff04009e470, info=0x7ff0556529c0) at 10.0/sql/sql_insert.cc:1835
 
#20 0x000000000065daad in mysql_insert (thd=0x7ff04d30b070, table_list=0x7ff04021d1a0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at 10.0/sql/sql_insert.cc:960
 
#21 0x000000000067d61e in mysql_execute_command (thd=0x7ff04d30b070) at 10.0/sql/sql_parse.cc:3432
 
#22 0x000000000068586f in mysql_parse (thd=0x7ff04d30b070, rawbuf=0x7ff04021d088 "insert INTO t1 values(date_format('2001-01-01','%W'))", length=53, parser_state=0x7ff055653630) at 10.0/sql/sql_parse.cc:6407
 
#23 0x0000000000678652 in dispatch_command (command=COM_QUERY, thd=0x7ff04d30b070, packet=0x7ff0423f2071 "insert INTO t1 values(date_format('2001-01-01','%W'))", packet_length=53) at 10.0/sql/sql_parse.cc:1299
 
#24 0x00000000006779f7 in do_command (thd=0x7ff04d30b070) at 10.0/sql/sql_parse.cc:996
 
#25 0x00000000007944aa in do_handle_one_connection (thd_arg=0x7ff04d30b070) at 10.0/sql/sql_connect.cc:1379
 
#26 0x00000000007941fd in handle_one_connection (arg=0x7ff04d30b070) at 10.0/sql/sql_connect.cc:1293
 
#27 0x0000000000ccb4a6 in pfs_spawn_thread (arg=0x7ff04d3d9df0) at 10.0/storage/perfschema/pfs.cc:1860
 
#28 0x00007ff055288b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#29 0x00007ff05378020d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from

 
revision-id: sergii@pisem.net-20141103164737-457hfby1eg82zol9
 
date: 2014-11-03 17:47:37 +0100
 
build-date: 2014-11-09 04:23:26 +0400
 
revno: 4471
 
branch-nick: 10.0



 Comments   
Comment by Jan Lindström (Inactive) [ 2015-02-04 ]

Debug assertion maybe too strict, no real affect on product builds.

Comment by Jan Lindström (Inactive) [ 2015-04-28 ]

Fix wrong.

Comment by Jan Lindström (Inactive) [ 2015-12-08 ]

http://lists.askmonty.org/pipermail/commits/2015-December/008706.html

Not sure if test case should contain other possible client charsets where mbminlen > 1.

Comment by Alexander Barkov [ 2015-12-08 ]

It seems date_format() creates a wrong result:

SET character_set_connection=ucs2;
 
SELECT HEX(date_format('2001-01-01','%W')) AS a;
 

+--------+
 
| a      |
 
+--------+
 
| 000057 |
 
+--------+

Notice, 3 bytes. In UCS2 length must be an even number.

Comment by Jan Lindström (Inactive) [ 2015-12-08 ]

Correct, with my fix it will give following result set

SET character_set_connection=ucs2;
SELECT hex(date_format('2001-01-01','%W'));
hex(date_format('2001-01-01','%W'))
004D006F006E006400610079

Comment by Alexander Barkov [ 2015-12-08 ]

These loops in make_date_time() and Item_func_date_format::format_length() stay as is since MySQL-4.0 time.
They should have been rewritten in 4.1 to use an mb_wc() loop, instead of directly referring to the string as an array of 8-bit characters, but they were not.
For some reasons no related bugs have been reported so far
Jan, I'm going to make a new version of the patch to use mb_wc()
(if you don't mind).
This will also help to handle utf16 and utf32 correctly.

Comment by Jan Lindström (Inactive) [ 2015-12-08 ]

I do not mind, if there is better and more correct way than directly referring to the string as an array of 8-bit characters, it should be used, I'm not familiar with those mb functions, so I fixed the issue with traditional methods, there could be other problems I did not yet explore.

Comment by Daniel Black [ 2018-01-01 ]

Fixed with f32091532da365db85d5441ddff212995e15aa9e it seems.

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