MySQL Bugs: #19057: Test 'rpl_row_func003' fails on SuSE SLES9 x86

Bug #19057	Test 'rpl_row_func003' fails on SuSE SLES9 x86
Submitted:	12 Apr 2006 17:51	Modified:	29 Aug 2006 13:14
Reporter:	Kent Boortz	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.1.10-pre	OS:	Linux (SuSE SLES9 x86)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
Running test case 'rpl_row_func003' crashes "mysqld"
on SuSE SLES9 x86. GDB on the core shows

 struct binlog_trx_data {
   bool empty() const
 =>{
     return pending == NULL && my_b_tell(&trans_log) == 0;
   }
   binlog_trx_data() {}
   IO_CACHE trans_log;                         // The transaction cache
   Rows_log_event *pending;                // The pending binrows event
 };

Stack trace

 #9  0x400d4ce9 in abort () from /lib/tls/libc.so.6
 #10 0x400ccce3 in __assert_fail () from /lib/tls/libc.so.6
 #11 0x08272337 in binlog_close_connection (thd=0x86d8f00) at log.cc:67
 #12 0x082bc3fa in closecon_handlerton (thd=0x46524b70, plugin=0x0, unused=0x0) at handler.cc:550
 #13 0x08350657 in plugin_foreach (thd=0x46524b70, func=0x82bc3c0 <closecon_handlerton>, type=1, arg=0x0) at sql_plugin.cc:899
 #14 0x082bd969 in ha_close_connection (thd=0x0) at handler.cc:558
 #15 0x081ce370 in ~THD (this=0x46524b70) at sql_class.cc:455
 #16 0x081e01e8 in end_thread (thd=0x46524b70, put_in_cache=true) at mysqld.cc:1738
 #17 0x08205497 in handle_one_connection (arg=0x46524b70) at sql_parse.cc:1203
 #18 0x40035a13 in start_thread () from /lib/tls/libpthread.so.0
 #19 0x401639da in clone () from /lib/tls/libc.so.6

How to repeat:
Running tests on SuSE SLES9 x86

extensively tested - OK - with current mysql-5.1-new-rpl tree and a version approximately of the time of the report: bk clone -r'1.2341' (after ChangeSet@1.2341, 2006-04-13 15:34:38+02:00, tomas@poseidon.ndb.mysql.com)
on the reported site and on dl145h where I could reproduce number of sles9's bugs.

Nothing came.

Support team please confirm it does not show up anymore. You might reactivate the test case upon success.

Rolling my request back, since the founder is me.

When the test is enabled back slave raises assertion with the stack

#3  0xb7ddbf71 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x0821ea16 in Field_long::val_int (this=0x936d7b8) at field.cc:3552
#5  0x08341eeb in Field::val_int_offset (this=0x936d7b8, row_offset=8)
    at field.h:249
#6  0x0835bd77 in ha_innobase::innobase_read_and_init_auto_inc (
    this=0x936d680, ret=0xb33fc798) at ha_innodb.cc:7072
#7  0x0835c3ad in ha_innobase::info (this=0x936d680, flag=86)
    at ha_innodb.cc:5686
#8  0x083b9675 in get_schema_tables_record (thd=0x92e9940, tables=0x93739e0, 
    table=0x934afc8, res=false, base_name=0x93365e8 "test", 
    file_name=0x93739d8 "t1") at sql_show.cc:2748
#9  0x083b8df7 in get_all_tables (thd=0x92e9940, tables=0x9335210, cond=0x0)
    at sql_show.cc:2613
#10 0x083c2386 in get_schema_tables_result (join=0x93724e0) at sql_show.cc:5073
#11 0x082cb108 in JOIN::exec (this=0x93724e0) at sql_select.cc:1377
#12 0x082cc9d1 in mysql_select (thd=0x92e9940, rref_pointer_array=0x92e9d38, 
    tables=0x9335210, wild_num=0, fields=@0x92e9c9c, conds=0x0, og_num=0, 
    order=0x0, group=0x0, having=0x0, proc_param=0x0, 
    select_options=2684635648, result=0x9336258, unit=0x92e99e4, 
    select_lex=0x92e9c14) at sql_select.cc:1958
---Type <return> to continue, or q <return> to quit---
#13 0x082ccc98 in handle_select (thd=0x92e9940, lex=0x92e9980, 
    result=0x9336258, setup_tables_done_option=0) at sql_select.cc:254
#14 0x08261f42 in execute_sqlcom_select (thd=0x92e9940, all_tables=0x9335210)
    at sql_parse.cc:5233
#15 0x08267940 in mysql_execute_command (thd=0x92e9940) at sql_parse.cc:2565
#16 0x0826fcaa in mysql_parse (thd=0x92e9940, 
    inBuf=0x9334630 "show table status like 't1'", length=27)
    at sql_parse.cc:6048

The failure's domain can be reduced to show up in this pretty simple script

bug.test

-- source include/not_ndb_default.inc
-- source include/have_innodb.inc
-- source include/have_binlog_format_row.inc
-- source include/master-slave.inc

# Begin clean up test section
connection master;
--disable_warnings
DROP TABLE IF EXISTS test.t1;

--enable_warnings

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);

sync_slave_with_master;
connection slave;
select * from test.t1;
show table status like 't1';

bug-slave.opt
--innodb

innodb and auto_inc are necessary.

This is what failed

550    longlong Field_long::val_int(void)
3551    {
3552      ASSERT_COLUMN_MARKED_FOR_READ;
3553      int32 j;

The bug is in that 'show table status' fails at the assertion fi innodb engine has not yet initialized auto_inc counter. The latter fact appeared to be a consequence of RBR but there is one more use case - just to start master mysqld and 'show table status' again finds the assertion.

I am filing new bug.
   Bug#20866: show table status on innodb raises assertion
which is should be considered the parent for this case. 
We can not simply close the old bug because I am not certain if mysqldump, that 
generates 'show table status' internally, does not have own problems as original report probably stated.
Yes, there were no regressions at beginning of June, but is better to wait for new bug resolution. Anyway the test has to be held down.

Set status to "analysing"

leaving bug#19057 back into "verified". Verification has to last as long as parent bug#20866 is being fixed.

assigning to me as I have a patch for BUG#20866 which fixes this one too.

Sent some questions to Chad

duplicate of BUG#20866

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...).

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/11012

ChangeSet@1.2288, 2006-08-29 17:37:48+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 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)

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)

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)