Bug #51787 Assertion `(n % 4) == 0' on slave upon INSERT into a table with UTF32 charset
Submitted: 6 Mar 2010 2:34 Modified: 15 Mar 2010 12:31
Reporter: Elena Stepanova Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S2 (Serious)
Version:mysql-next-mr-bugfixing OS:Any
Assigned to: Luis Soares CPU Architecture:Any
Triage: Triaged: D1 (Critical)

[6 Mar 2010 2:34] Elena Stepanova
Description:
The crash happens on debug version (5.5.99-m3-debug), in RBR or MBR mode

mysqld: mysql-5.5.99-m3/strings/ctype-ucs2.c:2128: my_vsnprintf_utf32: Assertion `(n % 4) == 0' failed.
100306  5:14:18 - mysqld got signal 6 ;

#7  0x0029934a in abort () from /lib/libc.so.6
#8  0x00290bd8 in __assert_fail () from /lib/libc.so.6
#9  0x0866d526 in my_vsnprintf_utf32 (dst=0xb3b4155a "varchar(500)", n=766, fmt=0x8777e67 "%s(%d)", ap=0xb3b414c0 "v~w\b\377")
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/strings/ctype-ucs2.c:2128
#10 0x0866d802 in my_snprintf_utf32 (cs=0x8a224e0, to=0xb3b4155a "varchar(500)", n=766, fmt=0x8777e67 "%s(%d)")
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/strings/ctype-ucs2.c:2219
#11 0x0831b463 in Field_string::sql_type (this=0xb6d117d8, res=...) at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/field.cc:6596
#12 0x0848cf92 in can_convert_field_to (field=0xb6d117d8, source_type=MYSQL_TYPE_STRING, metadata=52988, rli=0x98624d0, mflags=1, order_var=0xb3b41f08)
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/rpl_utility.cc:583
#13 0x0848de79 in table_def::compatible_with (this=0xb6d0b640, thd=0xb6d009a0, rli=0x98624d0, table=0xb6d10fe8, conv_table_var=0xb3b420a0)
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/rpl_utility.cc:784
#14 0x0840919a in Rows_log_event::do_apply_event (this=0xb6d02a70, rli=0x98624d0)
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/log_event.cc:7532
#15 0x0816a5a5 in Log_event::apply_event (this=0xb6d02a70, rli=0x98624d0) at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/log_event.h:1125
#16 0x08163b0d in apply_event_and_update_pos (ev=0xb6d02a70, thd=0xb6d009a0, rli=0x98624d0)
    at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/slave.cc:2310
#17 0x081640cf in exec_relay_log_event (thd=0xb6d009a0, rli=0x98624d0) at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/slave.cc:2470
#18 0x08164d27 in handle_slave_sql (arg=0x98611e8) at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/sql/slave.cc:3253
#19 0x08614c37 in pfs_spawn_thread (arg=0xb3a38910) at /export/home/pb2/build/sb_0-1516422-1267799925.16/mysql-5.5.99-m3/storage/perfschema/pfs.cc:1011
#20 0x00c21ab5 in start_thread () from /lib/libpthread.so.0
#21 0x0034783e in clone () from /lib/libc.so.6

How to repeat:
--source include/master-slave.inc

--disable_warnings
DROP DATABASE IF EXISTS systest;
--enable_warnings

CREATE DATABASE systest;
USE systest;

CREATE TABLE `t1` (
  `f1` char(255) DEFAULT NULL,
  KEY `f1` (`f1`)
) DEFAULT CHARSET=utf32;

CREATE TABLE `tlog` (
  `i1` int(11) NOT NULL AUTO_INCREMENT,
  `entry_dsc` varchar(500) DEFAULT NULL,
  PRIMARY KEY (`i1`)
) DEFAULT CHARSET=latin1;

delimiter //;
CREATE TRIGGER trg_ins AFTER INSERT ON t1 FOR EACH ROW
BEGIN
insert into tlog (entry_dsc)
values ('Inserted row');
END //
delimiter ;//

insert into t1 (f1) values ('insert into t1');

--sync_slave_with_master
[10 Mar 2010 17:34] Bugs System
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/102922

3119 Luis Soares	2010-03-10
      Fix for BUG#51716 and BUG#51787.
      
      In BUG#51787 we were using the wrong charset to print out the
      data. We were using the field charset for the string that would
      hold the information. This caused the assertion, because the
      string length was not aligned with UTF32 bytes requirements for
      storage.
      
      We fix this by using &my_charset_latin1 in the string object
      instead of the field->charset(). As a side-effect, we needed to
      extend the show_sql_type interface so that it took the field
      charset is now passed as a parameter, so that one is able to
      calculate the correct field size.
      
      In BUG#51716 we had issues with Field_string::pack and
      Field_string::unpack. When packing, the length was incorrectly
      calculated. When unpacking, the padding the string would be
      padded with the wrong bytes (a few bytes less than it should).
      
      We fix this by resorting to charset abstractions (functions) that
      calculate the correct length when packing and pad correctly the
      string when unpacking.
[10 Mar 2010 22:20] Bugs System
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/102945

3120 Luis Soares	2010-03-10
      Fix for BUG#51716 and BUG#51787: test case improvements.
      
      Split rpl_row_charset into:
      
        - rpl_row_utf16.
        - rpl_row_utf32.
      
      This way these tests can run independently if server supports
      either one of the charsets but not both.
      
      Cleaned up rpl_row_utf32 which had a spurious instruction:
      -- let $reset_slave_type_conversions= 0
[11 Mar 2010 8:00] Alexander Barkov
The patch http://lists.mysql.com/commits/102922 and
the post-fix http://lists.mysql.com/commits/102945 look fine.
[11 Mar 2010 11:08] Bugs System
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/102982

3814 Luis Soares	2010-03-11 [merge]
      Fix for BUG#51716 and BUG#51787: merge to 6.0-codebase-bugfixing.
      
      Manually merged tests changes:
      
        - rpl_row_utf16
          Removed the empty INSERT! Because of BUG@49100, the test would
          fail.
      
        - rpl_row_utf32
          Removed the warnings from the result file. Maximum key size is
          1332 bytes in 6.0, thence we don't get warnings.
[12 Mar 2010 18:11] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100312180926-0emfjrj8e9xnvl8h) (version source revid:alik@sun.com-20100312180447-2r0ak22y13s05134) (merge vers: 6.0.14-alpha) (pib:16)
[12 Mar 2010 18:12] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100312180838-rk60kn38g0qwt78n) (version source revid:alik@sun.com-20100312180435-wk7nvsbfntfus5bu) (pib:16)
[12 Mar 2010 18:22] Bugs System
Pushed into 5.5.3-m3 (revid:alik@sun.com-20100312181131-0b7v8r2htpd9jz2a) (version source revid:alik@sun.com-20100312181131-0b7v8r2htpd9jz2a) (merge vers: 5.5.3-m3) (pib:16)
[15 Mar 2010 12:31] Jon Stephens
Documented bugfic in the 5.5.3 and 6.0.14 changelogs as follows:

        When using the row-based or mixed replication format with a
        debug build of the MySQL server, inserts into columns using the
        UTF32 character set on the master caused the slave to crash.

Closed.