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.