MySQL Bugs: #43827: Server closes connections and restarts

Bug #43827	Server closes connections and restarts
Submitted:	24 Mar 2009 9:49	Modified:	29 Jun 2009 19:42
Reporter:	Francesco Battaglia	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.1.31, 5.0, 5.1 bzr	OS:	Linux
Assigned to:	Alexander Barkov	CPU Architecture:	Any

Description:
when I insert a field longer then max varchar field size mysql server closes all connections and restarts.

How to repeat:
I tried the workaround to add vietnamese collation in mysql community server 5.1.31.

see bug http://bugs.mysql.com/4745 

I created a db with this command:
CREATE DATABASE prova CHARACTER SET utf8 COLLATE utf8_vietnamese1_ci;

then I created a table:
create table prova (nome varchar(10))Engine=InnoDB;

when I try to insert a row longer then the field size for example:

insert into prova values ('01234567891');

I have this message:
Lost connection to MySQL server during query

The mysql server restart and close all connections giving this log:

/u01/app/mysql/bin/mysqld(my_print_stacktrace+0x21)[0x84d4341]
/u01/app/mysql/bin/mysqld(handle_segfault+0x381)[0x81fefa1]
/lib/tls/libpthread.so.0[0xd34a98]
/u01/app/mysql/bin/mysqld(_ZN15Field_varstring5storeEPKcjP15charset_info_st+0x1e
0)[0x81d9c30]
/u01/app/mysql/bin/mysqld(_ZN11Item_string13save_in_fieldEP5Fieldb+0x50)[0x81524
30]
/u01/app/mysql/bin/mysqld(_Z36fill_record_n_invoke_before_triggersP3THDPP5FieldR
4ListI4ItemEbP19Table_triggers_list14trg_event_type+0x4d)[0x824712d]
/u01/app/mysql/bin/mysqld(_Z12mysql_insertP3THDP10TABLE_LISTR4ListI4ItemERS3_IS5
_ES6_S6_15enum_duplicatesb+0xa50)[0x8282950]
/u01/app/mysql/bin/mysqld(_Z21mysql_execute_commandP3THD+0x1b19)[0x8210429]
/u01/app/mysql/bin/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x340)[0x8215fa0]
/u01/app/mysql/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x11
e0)[0x8217190]
/u01/app/mysql/bin/mysqld(_Z10do_commandP3THD+0xe0)[0x8217a10]
/u01/app/mysql/bin/mysqld(handle_one_connection+0x233)[0x8208663]
/lib/tls/libpthread.so.0[0xd2e3cc]
/lib/tls/libc.so.6(__clone+0x5e)[0xba81ae]
090324  9:42:36 - 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=8384512
read_buffer_size=131072
max_used_connections=6
max_threads=151
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337721 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x9382228
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...
stack_bottom = 0xb16973a8 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x938bbc8 = insert into prova values ('01234567891')
thd->thread_id=8
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090324 09:42:36 mysqld_safe Number of processes running now: 0
090324 09:42:36 mysqld_safe mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 0 42918596
090324  9:42:37  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 42918606
090324  9:42:37  InnoDB: Started; log sequence number 0 42918606
090324  9:42:37 [Note] Event Scheduler: Loaded 0 events
090324  9:42:37 [Note] /u01/app/mysql/bin/mysqld: ready for connections.
Version: '5.1.31'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server
 (GPL)

Any Idea???

Thank you for the report.

There are several links in bug #4745. Please describe step-by-step how you created utf8_vietnamese1_ci collation or provide your  share/mysql/charsets/Index.xml file

Hi Sveta!
Thanks for your reply!

I used the file http://vietunicode.sourceforge.net/howto/Index.xml

I copied this file in the folder mysql/share/charsets/ of mysql server

Changed title

Thank you for the feedback.

Verified as described.

Backtrace in my environment:

Thread 1 (process 32086):
#0  0x002ce402 in __kernel_vsyscall ()
#1  0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2  0x085a46c5 in my_write_core (sig=11) at stacktrace.c:310
#3  0x0824c685 in handle_segfault (sig=11) at mysqld.cc:2513
#4  <signal handler called>
#5  0x085b9c32 in my_scan_8bit (cs=0x968eec8, str=0x970e3ca "1", end=0x970e3cb "", sq=2) at ctype-simple.c:1115
#6  0x082146d3 in test_if_important_data (cs=0x968eec8, str=0x970e3ca "1", strend=0x970e3cb "") at field.cc:994
#7  0x08221158 in Field_longstr::report_if_important_data (this=0x970c9f0, ptr=0x970e3ca "1", end=0x970e3cb "", count_spaces=true) at field.cc:6354
#8  0x08222a40 in Field_varstring::store (this=0x970c9f0, from=0x970e3c0 "01234567891", length=11, cs=0x8866760) at field.cc:7050
#9  0x08183fdf in Item::save_str_value_in_field (this=0x970e3d0, field=0x970c9f0, result=0x970e3d8) at item.cc:373
#10 0x0818f69c in Item_string::save_in_field (this=0x970e3d0, field=0x970c9f0, no_conversions=false) at item.cc:4918
#11 0x082b047e in fill_record (thd=0x96b83a0, ptr=0x970c9ec, values=@0x970e3b0, ignore_errors=false) at sql_base.cc:8195
#12 0x082b0569 in fill_record_n_invoke_before_triggers (thd=0x96b83a0, ptr=0x970c9e8, values=@0x970e3b0, ignore_errors=false, triggers=0x0, event=TRG_EVENT_INSERT) at sql_base.cc:8238
#13 0x082f5291 in mysql_insert (thd=0x96b83a0, table_list=0x970e1d0, fields=@0x96b99d8, values_list=@0x96b99fc, update_fields=@0x96b99f0, update_values=@0x96b99e4, duplic=DUP_ERROR, ignore=false)
    at sql_insert.cc:778
#14 0x08264632 in mysql_execute_command (thd=0x96b83a0) at sql_parse.cc:3088
#15 0x0826af74 in mysql_parse (thd=0x96b83a0, inBuf=0x970e108 "insert into prova values ('01234567891')", length=40, found_semicolon=0xb73e62fc) at sql_parse.cc:5831
#16 0x0826bbb0 in dispatch_command (command=COM_QUERY, thd=0x96b83a0, packet=0x96fb1e9 "insert into prova values ('01234567891')", packet_length=40) at sql_parse.cc:1216
#17 0x0826cdce in do_command (thd=0x96b83a0) at sql_parse.cc:857
#18 0x08259a05 in handle_one_connection (arg=0x96b83a0) at sql_connect.cc:1115
#19 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#20 0x003b74fe in clone () from /lib/libc.so.6

This is a generic problem. MySQL will crash in this case with any
User-defined Unicode collation, with any storage engine.

An easier script to reproduce this:

mysql> create table t1 (nome varchar(10))character set utf8 collate utf8_vietnamese1_ci;
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values (repeat('a',11));
ERROR 2006 (HY000): MySQL server has gone away

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

2855 Alexander Barkov	2009-04-08
      Bug#43827 Server closes connections and restarts
      Problem:
        Crash happened with a user-defined utf8 collation,
        on attempt to insert a value longer than the column
        to store.
      Reason:
        The "ctype" member was not initialized (NULL) when
        allocating a user-defined utf8 collation, so an attempt
        to call my_ctype(cs, *str) to check if we loose any important
        data when truncating the value made the server crash.
      Fix:
        Initializing tge "ctype" member to a proper value.
      
      
      mysql-test/r/ctype_ldml.result
        Adding tests
      
      mysql-test/t/ctype_ldml.test
        Adding tests
      
      strings/ctype-uca.c
        Adding initialization of "ctype" member.

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

2855 Alexander Barkov	2009-04-08
      Bug#43827 Server closes connections and restarts
      Problem:
        Crash happened with a user-defined utf8 collation,
        on attempt to insert a value longer than the column
        to store.
      Reason:
        The "ctype" member was not initialized (NULL) when
        allocating a user-defined utf8 collation, so an attempt
        to call my_ctype(cs, *str) to check if we loose any important
        data when truncating the value made the server crash.
      Fix:
        Initializing tge "ctype" member to a proper value.
      
      
      mysql-test/r/ctype_ldml.result
        Adding tests
      
      mysql-test/t/ctype_ldml.test
        Adding tests
      
      strings/ctype-uca.c
        Adding initialization of "ctype" member.

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

2926 Alexander Barkov	2009-06-04
       Bug#43827 Server closes connections and restarts
      Problem:
        Crash happened with a user-defined utf8 collation,
        on attempt to insert a value longer than the column
        to store.
      Reason:
        The "ctype" member was not initialized (NULL) when
        allocating a user-defined utf8 collation, so an attempt
        to call my_ctype(cs, *str) to check if we loose any important
        data when truncating the value made the server crash.
      Fix:
        Initializing tge "ctype" member to a proper value.
      
      
      mysql-test/r/ctype_ldml.result
        Adding tests
      
      mysql-test/t/ctype_ldml.test
        Adding tests
      
      strings/ctype-uca.c
        Adding initialization of "ctype" member.
      
      modified:
        mysql-test/r/ctype_ldml.result
        mysql-test/t/ctype_ldml.test
        strings/ctype-uca.c

Pushed into  mysql-5.1.36-bugteam

Pushed into 5.1.36 (revid:joro@sun.com-20090616102155-3zhezogudt4uxdyn) (version source revid:azundris@mysql.com-20090606160500-zm37psz7u1m96y5l) (merge vers: 5.1.36) (pib:6)

Pushed into 5.4.4-alpha (revid:alik@sun.com-20090616183122-chjzbaa30qopdra9) (version source revid:azundris@mysql.com-20090606160423-aym8s5rn51nmg387) (merge vers: 6.0.12-alpha) (pib:11)

I had another problem with vietnamese collation.

I added this comment here because I don't know if my new problem is linked to this bug.

to reproduce:

CREATE DATABASE prova CHARACTER SET utf8 COLLATE utf8_vietnamese1_ci;

create table prova (nome varchar(10))Engine=InnoDB;

insert into prova (nome) values ('hello!');

select * from prova where lower(nome)=lower('N');

When I use the function lower on a field created with vietnamese collation
db closes all connection and restarts

thi is the log:

090618 12:48:57 - 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=8384512
read_buffer_size=131072
max_used_connections=11
max_threads=151
threads_connected=11
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337720 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0xac03828
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...
stack_bottom = 0xb15ff210 thread_stack 0x30000
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xab2d0c0 = select * from prova where lower(nome)=lower('N')
thd->thread_id=15
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

I found this issue on MySQL 5.1.32 
SO: Red Hat Enterprise Linux Server release 5.2

Noted in 5.1.36, 5.4.4 changelogs.

For user-defined utf8 collations, attempts to store values too long
for a column could cause a server crash.

for version 5.0.83:

ALTER TABLE [tablename] CONVERT TO CHARACTER SET utf8 COLLATE utf8_vietnamese1_ci;

ERROR 2013 (HY000): Lost connection to MySQL server during query

Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.

Ignore previous comment about 5.4.2.

Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)

Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)

Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)

Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)

The 5.4 fix has been pushed to 5.4.2.