MySQL Bugs: #20866: show table status on innodb raises assertion

Bug #20866	show table status on innodb raises assertion
Submitted:	5 Jul 2006 13:49	Modified:	18 Jun 2010 12:46
Reporter:	Andrei Elkin	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	5.1.12	OS:	Linux (Ubuntu 5.10)
Assigned to:	Guilhem Bichot	CPU Architecture:	Any

Description:
Working with Bug#19057  Test 'rpl_row_func003' fails on SuSE SLES9 x86
I enabled the test to see that there is a segfault when
mysqldump sends "show table status like 't1'" to slave server.

But we don't need replication to hit the same failure.
The bug is in that 'show table status' fails at the assertion if innodb engine has not yet initialized auto_inc counter.

 start master mysqld and 'show table status' again finds the assertion.

#3  0xb7d87f71 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x0821ea16 in Field_long::val_int (this=0x92feb18) at field.cc:3552
#5  0x08341eeb in Field::val_int_offset (this=0x92feb18, row_offset=8)
    at field.h:249
#6  0x0835bd77 in ha_innobase::innobase_read_and_init_auto_inc (
    this=0x92fe9e0, ret=0xb21e6798) at ha_innodb.cc:7072
#7  0x0835c3ad in ha_innobase::info (this=0x92fe9e0, flag=86)
    at ha_innodb.cc:5686
#8  0x083b9675 in get_schema_tables_record (thd=0x92cdf20, tables=0x930bd18, 
    table=0x93064c0, res=false, base_name=0x93013f8 "test", 
    file_name=0x930bd10 "t1") at sql_show.cc:2748
#9  0x083b8df7 in get_all_tables (thd=0x92cdf20, tables=0x9300020, cond=0x0)
    at sql_show.cc:2613
#10 0x083c2386 in get_schema_tables_result (join=0x930a818) at sql_show.cc:5073
#11 0x082cb108 in JOIN::exec (this=0x930a818) at sql_select.cc:1377
#12 0x082cc9d1 in mysql_select (thd=0x92cdf20, rref_pointer_array=0x92ce318, 
    tables=0x9300020, wild_num=0, fields=@0x92ce27c, conds=0x0, og_num=0, 
    order=0x0, group=0x0, having=0x0, proc_param=0x0, 
    select_options=2684635648, result=0x9301068, unit=0x92cdfc4, 
    select_lex=0x92ce1f4) at sql_select.cc:1958
#13 0x082ccc98 in handle_select (thd=0x92cdf20, lex=0x92cdf60, 
    result=0x9301068, setup_tables_done_option=0) at sql_select.cc:254
#14 0x08261f42 in execute_sqlcom_select (thd=0x92cdf20, all_tables=0x9300020)
    at sql_parse.cc:5233
#15 0x08267940 in mysql_execute_command (thd=0x92cdf20) at sql_parse.cc:2565
#16 0x0826fcaa in mysql_parse (thd=0x92cdf20, 
    inBuf=0x92ff440 "show table status like 't1'", length=27)
    at sql_parse.cc:6048

If the bug will be confirmed please aware of bug#19057 is waiting to this one since it shares the test case.

How to repeat:
let $engine_type=INNODB;

eval CREATE TABLE test.t1 (a INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(a)) ENGINE=$engine_type;
INSERT INTO test.t1 VALUES (1);

mysqladmin shutdown

start the server again
show table status like 't1'

Suggested fix:
Only a hint.

The assertion at Field_long::val_int
was introduced with
ChangeSet
  1.2386 06/06/04 18:52:22 monty@mysql.com +136 -0
  This changeset is largely a handler cleanup changeset (WL#3281), but includes fixes and cleanups that was found necessary while testing the handler changes
  changes that requires code changes in other code of other storage engines.
  (Note that all changes are very straightforward and one should find all issues
  by compiling a --debug build and fixing all compiler errors and all
  asserts in field.cc while running the test suite),
  

Particullarily about the assertion

 sql/field.cc
    1.311 06/06/04 18:52:07 monty@mysql.com +164 -39
    Added ASSERT_COLUMN_MARKED_FOR_WRITE in all store() methods and ASSERT_COLUMN_MARKED_FOR_READ in all val() methods to catch wrong setting if table->read_set and table->write_set

Please search for dbug_tmp_use_all_columns in http://lists.mysql.com/internals/33654.

Without having looked at the test case, I guess that the auto-increment column does not belong to the result set of the query.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/9208

This might have something to do with http://bugs.mysql.com/bug.php?id=20493

A patch that was submitted merely modified disabled to blame this bug, instead of bug#19057 for rpl_row_func003 is on-hold.

"Patch pending" state was set occasionally wrong!

Note, that Bug#21173 should relate to this one or simply a dup.

Heikki, don't bother, I have a patch for this, I'll fix:

===== ha_innodb.cc 1.286 vs edited =====
*** /tmp/bk_ha_innodb.cc-1.286_wl9WMI   2006-08-28 14:35:28 +02:00
--- edited/ha_innodb.cc 2006-08-28 14:06:15 +02:00
***************
*** 7063,7072 ****
                'found_next_number_field' below because MySQL in SHOW TABLE
                STATUS does not seem to set 'next_number_field'. The comment
                in table.h says that 'next_number_field' is set when it is
!               'active'. */

                auto_inc = (longlong) table->found_next_number_field->
                                val_int_offset(table->s->rec_buff_length) + 1;
        }

        dict_table_autoinc_initialize(prebuilt->table, auto_inc);
--- 7063,7078 ----
                'found_next_number_field' below because MySQL in SHOW TABLE
                STATUS does not seem to set 'next_number_field'. The comment
                in table.h says that 'next_number_field' is set when it is
!               'active'.
!                 Since 5.1 MySQL enforces that we announce fields which we will
!                 read; as we only do a val_*() call, dbug_tmp_use_all_columns()
!                 is sufficient. */

+                 my_bitmap_map *old_map;
+                 old_map= dbug_tmp_use_all_columns(table, table->read_set);
                auto_inc = (longlong) table->found_next_number_field->
                                val_int_offset(table->s->rec_buff_length) + 1;
+                 dbug_tmp_restore_column_map(table->read_set, old_map);
        }

        dict_table_autoinc_initialize(prebuilt->table, auto_inc);

Setting Chad as Lead as I'll push in his tree.

sent some questions to Chad

by the way the problem exists only in debug builds

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/11009

ChangeSet@1.2288, 2006-08-29 15:35:05+02:00, guilhem@gbichot3.local +2 -0
  Fix for BUG#20866 "show table status on innodb raises assertion"
  and its duplicate BUG#19057 "Test 'rpl_row_func003' fails on SuSE SLES9 x86".
  It was an assertion failure, only in debug builds, not present
  in released versions (nothing to document).
  It happened when doing SHOW TABLE STATUS on an InnoDB table
  having an auto_increment column, right after creating the table.
  The test which would have caught this problem was disabled in 
  mid-April for another reason (how much I like tests disabled for
  months...).

pushed in 5.1-maint tree. Nothing to document (bug was not released).

Pushed to 5.1.12

Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug. Re-closing.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)