MySQL Bugs: #27404: util thd mysql_parse sig11 when mysqld default multibyte charset

Bug #27404	util thd mysql_parse sig11 when mysqld default multibyte charset
Submitted:	23 Mar 2007 16:41	Modified:	31 Jul 2007 6:08
Reporter:	Jonathan Miller	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S1 (Critical)
Version:	mysql-5.1-telco, 5.1.18bk	OS:	Linux (Linux 32 Bit OS)
Assigned to:	Stewart Smith	CPU Architecture:	Any

Description:
CURRENT_TEST: ctype_ucs2_def:

key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=0
max_threads=151
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 59829 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0xa19a810
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb2b7ee18, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8215944
0x81668ad
0x823e1e7
0x822e0a9
0x8323fde

0x8215944 _Z13get_lock_dataP3THDPP8st_tablejjS3_ + 584
0x81668ad _init + 1853
0x823e1e7 _ZN16sys_var_bool_ptrD0Ev + 43
0x822e0a9 _Z21mysql_execute_commandP3THD + 17483
0x8323fde _Z22execute_ddl_log_actionP3THDP16st_ddl_log_entry + 196

CURRENT_TEST: group_min_max:

070322 22:03:30 [Note] NDB Binlog: logging ./test/t2
070322 22:03:31 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1

thd: 0xa9eb640
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb2a09468, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8215944
0x828ec9e
0x829026f
0x8292759
0x8292ed2
0x828de03
0x828fdbc
0x829009b
0x8292759
0x8292ed2
0x8221789
0x8227e20
0x822e167
0x822e6f9
0x822f96f
0x821e84e
0xd1ebd4
0xc764fe

0x8215944 _Z13get_lock_dataP3THDPP8st_tablejjS3_ + 584
0x828ec9e _ZN4JOIN8optimizeEv + 8114
0x829026f _Z15select_describeP4JOINbbbPKc + 3789
0x8292759 _ZN4JOIN4execEv + 6041
0x8292ed2 _Z13handle_selectP3THDP6st_lexP13select_resultm + 436
0x828de03 _ZN4JOIN8optimizeEv + 4375
0x828fdbc _Z15select_describeP4JOINbbbPKc + 2586
0x829009b _Z15select_describeP4JOINbbbPKc + 3321
0x8292759 _ZN4JOIN4execEv + 6041
0x8292ed2 _Z13handle_selectP3THDP6st_lexP13select_resultm + 436
0x8221789 _ZN6I_ListI8i_stringE4headEv + 21
0x8227e20 _ZN13st_select_lex17add_table_to_listEP3THDP11Table_identP10LEX_STRINGm13thr_lock_typeP4ListI10index_hintES5_ + 614
0x822e167 _Z21mysql_execute_commandP3THD + 17673
0x822e6f9 _Z21mysql_execute_commandP3THD + 19099
0x822f96f _Z21mysql_execute_commandP3THD + 23825
0x821e84e _Z20mysql_init_variablesv + 1242
0xd1ebd4 (?)
0xc764fe (?)

CURRENT_TEST: lowercase_table

key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1

0x8215944
0x826c3b7
0x82f39a3
0x83317c2
0x822c1d4
0x822e167
0x822e6f9
0x822f96f
0x821e84e
0xd1ebd4
0xc764fe

0x8215944 _Z13get_lock_dataP3THDPP8st_tablejjS3_ + 584
0x826c3b7 _Z15open_binary_frmP3THDP14st_table_sharePhi + 7805
0x82f39a3 _Z14ha_init_errorsv + 599
0x83317c2 _Z19mysql_rename_tablesP3THDP13st_table_listb + 98
0x822c1d4 _Z21mysql_execute_commandP3THD + 9590
0x822e167 _Z21mysql_execute_commandP3THD + 17673
0x822e6f9 _Z21mysql_execute_commandP3THD + 19099
0x822f96f _Z21mysql_execute_commandP3THD + 23825
0x821e84e _Z20mysql_init_variablesv + 1242
0xd1ebd4 (?)
0xc764fe (?)

CURRENT_TEST: partition_mgm_err

0x8215944
0xc0eadc
0xc0fe78
0xc11587
0x85302bd
0x84e723b
0x84e793e
0x84ea5ea
0x84d563c
0x84d568b
0x85419ac
0x85149f5
0x8513065
0x853fd52
0x8541367
0x854141d
0x8541513
0x84f9100
0x84f9630
0x84f9684
0x84e8c90
0x84e8d47
0x84ce57c
0x8324535
0xd1ebd4
0xc764fe

0x8215944 _Z13get_lock_dataP3THDPP8st_tablejjS3_ + 584
0xc0eadc (?)
0xc0fe78 (?)
0xc11587 (?)
0x85302bd _GLOBAL__I__Z11reportErrorPvt16TransporterErrorPKc + 7
0x84e723b _ZN16NdbDictInterface18createOrAlterTableER3NdbR12NdbTableImplb + 4303   All
0x84e793e _ZN12NdbTableImpl6assignERKS_ + 334
0x84ea5ea _ZN17NdbDictionaryImpl16createBlobTablesER12NdbTableImplS1_ + 82
0x84d563c .L174 + 74
0x84d568b .L174 + 153
0x85419ac mark_blocks_free + 98
0x85149f5 _ZNK12ConfigValues13ConstIterator3getEjPPKc + 65
0x8513065 ndb_mgm_stop3 + 713
0x853fd52 my_b_append_tell + 20
0x8541367 my_multi_malloc + 79
0x854141d init_alloc_root + 61
0x8541513 reset_root_defaults + 124
0x84f9100 _ZN12NdbIndexStat11stat_deleteERNS_4AreaEj + 342
0x84f9630 _ZN12NdbIndexStat16records_in_rangeEPKN13NdbDictionary5IndexEP21NdbIndexScanOperationyPyi + 150
0x84f9684 _ZN12NdbIndexStat16records_in_rangeEPKN13NdbDictionary5IndexEP21NdbIndexScanOperationyPyi + 234
0x84e8c90 _ZN12NdbEventImplC2Ev + 168
0x84e8d47 _ZN12NdbTableImpl15buildColumnHashEv + 157
0x84ce57c _ZN14NdbEventBuffer10merge_dataEPK12SubTableDataP16LinearSectionPtrP12EventBufDataPj + 174
0x8324535 _Z27write_execute_ddl_log_entryjbPP23st_ddl_log_memory_entry + 221
0xd1ebd4 (?)

How to repeat:
ndbdev@ndb08:/data1/mysql-5.1-telco/mysql-test> ./mysql-test-run.pl --force --mysqld=--default-storage-engine=ndb --mysqld=--binlog-format=row --ndb-extra-test --use-ndbcluster

Note: I had to edit the MySQL-TEST-RUN.pl and add an option of --use-ndbcluster to allow the cluster to start and be used for non cluster tests. This is not checked in anywhere currently.

our $opt_use_ndbcluster= 0;

# Check if cluster can be skipped
if ( !$need_ndbcluster && !$opt_use_ndbcluster)

'use-ndbcluster'          => \$opt_use_ndbcluster,

if ( ! $opt_skip_ndbcluster and
     !$clusters->[0]->{'pid'} and
     $tinfo->{'ndb_test'} || $opt_use_ndbcluster)

mysql-test-run.pl patch

Attachment: tomas.patch (application/octet-stream, text), 1.28 KiB.

Also reproduced in 5.1.18bk tree

new version of tomas.patch for latest 5.1 bk

Attachment: test_run_use_ndbcluster.patch (text/x-patch), 1.50 KiB.

NDB util thread calls mysql_parse internally with plain old c strings (7bit ascii) to create tables (e.g. mysql.ndb_schema). With mysqld default charset set to a multibyte one (e.g. ucs2) mysql_parse would try to interpret the 7bit string as UCS2 and promptly explode in a heap.

Solution is to set the util thread to be using utf8 charset.

patch for util thread

Attachment: bug27404_cs_util_thread.patch (text/x-patch), 1.30 KiB.

Tomas - may this also be needed for the injector thread? Gut feeling says yes...

test for ndb master ucs2, slave default

Attachment: ndb_rpl_ctype_ucs2_def_test.patch (text/x-patch), 2.28 KiB.

backtrace of slave:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7f15617 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0837492b in write_core (sig=6) at stacktrace.c:229
#3  0x081e4763 in handle_segfault (sig=6) at mysqld.cc:2237
#4  <signal handler called>
#5  0xffffe410 in __kernel_vsyscall ()
#6  0xb7ca3770 in raise () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7ca4ef3 in abort () from /lib/tls/i686/cmov/libc.so.6
#8  0xb7c9cdbb in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#9  0x082a99da in Rows_log_event::do_apply_event (this=0x87f8f28, 
    rli=0x8805e90) at log_event.cc:6040
#10 0x083607b0 in exec_relay_log_event (thd=0x88038d8, rli=0x8805e90)
    at log_event.h:815
#11 0x08361398 in handle_slave_sql (arg=0x8805010) at slave.cc:2403
#12 0xb7f11504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0xb7d4751e in clone () from /lib/tls/i686/cmov/libc.so.6

bit of *rli:

      name = 0x87e6f70 "/home/stewart/Documents/MySQL/5.1/ndb-work/mysql-test/var/log/slave-relay-bin", 
      log_file_name = "/home/stewart/Documents/MySQL/5.1/ndb-work/mysql-test/var/log/slave-relay-bin.000003\000\000\000\000\000\000\000\000l+\200\b�]\200\b", '\0' <repeats 20 times>, "xl\200\b\000\000\000\000xl\200\bxl\200\b\000\000\000\000xl\200\b\000\000\000\000X_\200\b\\_\200\b", '\0' <repeats 68 times>, "��J\b߿J\b\001", '\0' <repeats 35 times>, "\037", '\0' <repeats 12 times>, "@\000\000\000@\000\000 ", '\0' <repeats 18 times>..., time_buff = '\0' <repeats 19 times>, 
      db = '\0' <repeats 192 times>, write_error = false, inited = true, 
      log_file = {pos_in_file = 728, end_of_file = 1068, 
        read_pos = 0x8812eaf "��hF\027\001", read_end = 0x8812f24 "", 
        buffer = 0x8812dd0 "��hF\002\001", 

bit of the relay log:
# at 1003
#768 16:40:16 server id 1  end_log_pos 922 
# Position  Timestamp   Type   Master ID        Size      Master Pos    Flags 
#      3eb d0 f9 68 46   02   01 00 00 00   41 00 00 00   9a 03 00 00   00 00
#      3fe 00 00 00 00 01 00 00 00  00 00 00 1a 00 00 00 40 |................|
#      40e 00 00 01 00 00 00 00 00  00 00 00 06 03 73 74 64 |.............std|
#      41e 04 21 00 21 00 80 00 00  43 4f 4d 4d 49 54  |........COMMIT|
#       Query   thread_id=0     exec_time=1     error_code=0
SET TIMESTAMP=1181284816/*!*/;
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

patch for binlog thread

Attachment: bug27404_cs_binlog_thread.patch (text/x-patch), 830 bytes.

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7f6a617 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x083748eb in write_core (sig=11) at stacktrace.c:229
#3  0x081e4763 in handle_segfault (sig=11) at mysqld.cc:2237
#4  <signal handler called>
#5  0x0813017b in MYSQLlex (arg=0xb7234184, yythd=0x88038d0) at sql_lex.cc:596
#6  0x0820bb8c in MYSQLparse (yythd=0x88038d0) at sql_yacc.cc:14840
#7  0x081fb9a6 in mysql_parse (thd=0x88038d0, inBuf=0x884de55 "BEGIN", 
    length=5, found_semicolon=0xb72342c0) at sql_parse.cc:5325
#8  0x082ab0f4 in Query_log_event::do_apply_event (this=0x87f5670, 
    rli=0x8805e90, query_arg=0x884de55 "BEGIN", q_len_arg=5)
    at log_event.cc:2057
#9  0x082ab7fa in Query_log_event::do_apply_event (this=0x87f5670, 
    rli=0x8805e90) at log_event.cc:1907
#10 0x08360770 in exec_relay_log_event (thd=0x88038d0, rli=0x8805e90)
    at log_event.h:815
#11 0x08361358 in handle_slave_sql (arg=0x8805010) at slave.cc:2403
#12 0xb7f66504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0xb7d9c51e in clone () from /lib/tls/i686/cmov/libc.so.6

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

ChangeSet@1.2543, 2007-06-30 18:02:38+10:00, stewart@flamingspork.com +1 -0
  [PATCH] BUG#27404 util thd mysql_parse sig11 when mysqld default multibyte charset
  
  NDB util thread calls mysql_parse internally with plain old c strings (7bit ascii) to create tables (e.g. mysql.ndb_schema). With mysqld default charset set to a multibyte one (e.g. ucs2) mysql_parse would try to interpret the 7bit string as UCS2 and promptly explode in a heap.
  
  Solution is to set the util thread to be using utf8 charset.
  
  Index: ndb-work/sql/ha_ndbcluster.cc
  ===================================================================

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

ChangeSet@1.2544, 2007-06-30 18:02:54+10:00, stewart@flamingspork.com +3 -0
  [PATCH] Test for BUG#27404 util thd mysql_parse sig11 when default multibyte charset
  
  Test that we can start a MySQL Server with a default multibyte charset with
  NDB running. Test *really* basic functionality too.
  
  Index: ndb-work/mysql-test/r/rpl_ndb_ctype_ucs2_def.result
  ===================================================================

pushed to 5.1-ndb

Pushed into 5.1.21-beta

This bug (well, the re-enabling of the test case) is on hold at least until these bugs are fixed:

BUG#29562, BUG#29563 and BUG#29564

which is likely rpl team.

Document this fix, things don't 100% work yet (see other bugs).

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Documented bugfix in 5.1.21 changelog. Noted limitations for Cluster replication in Cluster chapter as suggested by Stewart.