| Bug #59488 | Error trying to access page and assertion in fil0fil.c line 4407 with ICP on | ||
|---|---|---|---|
| Submitted: | 13 Jan 2011 23:12 | Modified: | 3 Aug 2011 15:06 |
| Reporter: | Elena Stepanova | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
| Version: | 5.6.1-m5 | OS: | Any |
| Assigned to: | Marko Mäkelä | CPU Architecture: | Any |
[13 Jan 2011 23:12]
Elena Stepanova
[13 Jan 2011 23:18]
Elena Stepanova
Assertion and stack trace for the debug version, same test case:
InnoDB: Assertion failure in thread 1174985024 in file mysql-5.6.1-m5/storage/innobase/rem/rem0rec.c line 812
InnoDB: Failing assertion: len <= col->len || col->mtype == 5
#5 0x00002b3e3fd5ffb0 in abort () from /lib64/libc.so.6
#6 0x00000000009895c0 in rec_get_converted_size_comp_prefix (index=0x156a258, fields=<value optimized out>, n_fields=7, extra=0x0)
at mysql-5.6.1-m5/storage/innobase/rem/rem0rec.c:812
#7 0x00000000009898b7 in rec_get_converted_size_comp (index=0x156a258, status=<value optimized out>, fields=0x15e10c0, n_fields=7, extra=0x0)
at mysql-5.6.1-m5/storage/innobase/rem/rem0rec.c:893
#8 0x00000000008b027c in rec_get_converted_size (index=0x156a258, dtuple=0x15e1088, n_ext=0)
at mysql-5.6.1-m5/storage/innobase/include/rem0rec.ic:1566
#9 0x00000000008b0972 in btr_cur_optimistic_insert (flags=0, cursor=0x4608b190, entry=0x15e1088, rec=0x4608b188, big_rec=0x4608b180, n_ext=0,
thr=0x15b1438, mtr=0x4608acb0) at mysql-5.6.1-m5/storage/innobase/btr/btr0cur.c:1216
#10 0x0000000000991044 in row_ins_index_entry_low (mode=2, index=0x156a258, entry=0x15e1088, n_ext=0, thr=0x15b1438)
at mysql-5.6.1-m5/storage/innobase/row/row0ins.c:2107
#11 0x0000000000993a0c in row_ins_index_entry (index=0x156a258, entry=0x15e1088, n_ext=0, foreign=<value optimized out>, thr=0x15b1438)
at mysql-5.6.1-m5/storage/innobase/row/row0ins.c:2188
#12 0x00000000009945f9 in row_ins_step (thr=0x15b1438)
at mysql-5.6.1-m5/storage/innobase/row/row0ins.c:2273
#13 0x000000000084e098 in row_insert_for_mysql (mysql_rec=0x15ae5e0 "К", prebuilt=0x156d308)
at mysql-5.6.1-m5/storage/innobase/row/row0mysql.c:1201
#14 0x000000000083430b in ha_innobase::write_row (this=0x15ae320, record=0x15ae5e0 "К")
at mysql-5.6.1-m5/storage/innobase/handler/ha_innodb.cc:5414
#15 0x000000000069bed4 in handler::ha_write_row (this=0x15ae320, buf=0x15ae5e0 "К")
at mysql-5.6.1-m5/sql/handler.cc:5854
#16 0x000000000056c263 in write_record (thd=0x15320d0, table=0x15b3330, info=0x4608b8b0)
at mysql-5.6.1-m5/sql/sql_insert.cc:1734
#17 0x0000000000573d36 in mysql_insert (thd=0x15320d0, table_list=0x157fbb8, fields=@0x1534830, values_list=@0x1534878, update_fields=@0x1534860,
update_values=@0x1534848, duplic=DUP_ERROR, ignore=false) at mysql-5.6.1-m5/sql/sql_insert.cc:928
#18 0x000000000058484b in mysql_execute_command (thd=0x15320d0) at mysql-5.6.1-m5/sql/sql_parse.cc:2845
#19 0x00000000005885c8 in mysql_parse (thd=0x15320d0, rawbuf=0x157fa90 "INSERT INTO table1 (i2, c1) VALUES\n(0 , 3767074816), (5 , 27)",
length=<value optimized out>, parser_state=0x4608cd60) at mysql-5.6.1-m5/sql/sql_parse.cc:5550
#20 0x00000000005894f8 in dispatch_command (command=COM_QUERY, thd=0x15320d0,
packet=0x1577a61 "INSERT INTO table1 (i2, c1) VALUES\n(0 , 3767074816), (5 , 27)", packet_length=61)
at mysql-5.6.1-m5/sql/sql_parse.cc:1078
#21 0x000000000058a993 in do_command (thd=0x15320d0) at mysql-5.6.1-m5/sql/sql_parse.cc:815
#22 0x000000000062bd7f in do_handle_one_connection (thd_arg=<value optimized out>)
at mysql-5.6.1-m5/sql/sql_connect.cc:748
#23 0x000000000062be4a in handle_one_connection (arg=<value optimized out>)
at mysql-5.6.1-m5/sql/sql_connect.cc:684
#24 0x0000000000a05d1a in pfs_spawn_thread (arg=<value optimized out>)
at mysql-5.6.1-m5/storage/perfschema/pfs.cc:1360
#25 0x00002b3e3f780143 in start_thread () from /lib64/libpthread.so.0
#26 0x00002b3e3fdef8cd in clone () from /lib64/libc.so.6
#27 0x0000000000000000 in ?? ()
[3 Aug 2011 14:21]
Marko Mäkelä
Is this still repeatable?
[3 Aug 2011 15:06]
Elena Stepanova
No, it's gone, not reproducible on the current trunk. Possibly it was fixed along with bug#59483, in any case I'm closing it.
