MySQL Bugs: #60929: mysql 5.5.9 64 bit crashing while replicating the load data infile

Bug #60929	mysql 5.5.9 64 bit crashing while replicating the load data infile
Submitted:	19 Apr 2011 22:38	Modified:	18 Nov 2017 22:54
Reporter:	sanjeev sagar	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.5.9, 5.5.11	OS:	Linux (Linux 2.6.18-194.el5 #1 SMP ... x86_64 GNU/Linux)
Assigned to:		CPU Architecture:	Any
Tags:	mysqld got signal 6

Description:
mysql 5.5.9 replication crashing the server with signal 6 or 11 while playing the Load data infile statement on the db with binlog_format=STATEMENT. This is the default in 5.5

mysqld: /export/home/pb2/build/sb_0-2859905-1295553452.13/mysql-5.5.9/mysys/my_new.cc:51: int __cxa_pure_virtual(): Assertion `! "Aborted: pure virtual method called."' failed.
110419  6:30:11 - mysqld got signal 6 ;

110419 13:55:17 - 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=314572800
read_buffer_size=2097152
max_used_connections=2
max_threads=300
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 
3382617 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0xd3e6f20
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 = 0x415410f8 thread_stack 0x30000
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x39)[0x794a09]
/usr/local/mysql/bin/mysqld(handle_segfault+0x380)[0x4fcc60]
/lib64/libpthread.so.0[0x3002c0eb10]
/usr/local/mysql/bin/mysqld[0x75236d]
/usr/local/mysql/bin/mysqld(_Z10mysql_loadP3THDP12sql_exchangeP10TABLE_LISTR4ListI4ItemES8_S8_15enum_duplicatesbb+0x151e)[0x
75633e]
/usr/local/mysql/bin/mysqld(_ZN14Load_log_event14do_apply_eventEP6st_netPK14Relay_log_infob+0x944)[0x710194]
/usr/local/mysql/bin/mysqld(_ZN22Execute_load_log_event14do_apply_eventEPK14Relay_log_info+0x285)[0x7129a5]
/usr/local/mysql/bin/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x125)[0x515295]
/usr/local/mysql/bin/mysqld[0x519c52]
/usr/local/mysql/bin/mysqld(handle_slave_sql+0xa7c)[0x51c0bc]
/lib64/libpthread.so.0[0x3002c0673d]
/lib64/libc.so.6(clone+0x6d)[0x30020d40cd]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0xd3edcf8): LOAD DATA INFILE 
'/mysql/db01/tmp/SQL_LOAD-1101600-1101503-9.data' IGNORE INTO TABLE 
`mpcounter` FIELDS T
ERMINATED BY '|' ENCLOSED BY '' ESCAPED BY '\\' LINES TERMINATED BY '\n' 
(member_id ,COUNTER_START_DATE ,COUNTER_END_DATE ,g
oal ,actual ,bonus ,updtype1 ,updtype2 ,updtype3 ,updtype4 ,updtype5)

How to repeat:
use test;

CREATE TABLE mpcounter (member_id int, COUNTER_START_DATE date, 
COUNTER_END_DATE date, goal int, actual int, bonus int, updtype1 
varchar(10), updtype2 varchar(10), updtype3 varchar(10), updtype4 
varchar(10), updtype5 varchar(10));

LOAD DATA INFILE '/mysql/db01/tmp/SQL_LOAD-1101700-1101500-5.data' 
IGNORE INTO TABLE `mpcounter` FIELDS TERMINATED BY '|' ENCLOSED BY '' 
ESCAPED BY '\\' LINES TERMINATED BY '\n' (member_id ,COUNTER_START_DATE 
,COUNTER_END_DATE ,goal ,actual ,bonus ,updtype1 ,updtype2 ,updtype3 
,updtype4 ,updtype5);

DATA:

66079|2011-01-01|2012-01-01|3|1|10|NOUPD|END|NOUPD|ACTUAL|NOUPD
543194|2011-01-01|2012-01-01|10|3|20|NOUPD|NOUPD|NOUPD|ACTUAL|NOUPD
566846|2011-01-01|2012-01-01|10|2|20|NOUPD|NOUPD|NOUPD|ACTUAL|NOUPD

Could you please try latest released version. I couldn't repeat with today source server. Thanks in advance.

I've tested with latest mysql 5.5.11 (GA) and this bug still exist there. 

mysql 5.6.2 is not GA and i can not test till the product is GA.

Could you please advise how can i get any patch to fix this. We need this for our upgrade to mysql 5.5 ?

Appreciate it.

So, you just run statements from "How to repeat" on master (with file to load containing only that rows of data) and get the crash on slave? 

Please, confirm, as I can not repeat this with current mysql-5.5 (5.5.13) on Mac for some reason.

Mysql version and environment is different. 

I'm on RHEL5 mysql 5.5.9 or 5.5.11 64 bit. 

Yes it does crash if you go as per the "how to repeat".

I don't see 5.5.13 in the download GA section. 

Please test on the same release version.

Appreciate it.

Thank you for the feedback.

I can not repeat described behavior too. Please send your configuration file.

I couldn't repeat on Windows 64-bit with debug built too.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

We are experiencing this issue on mysql-5.5.46 on CentOS 6.3

160201 18:18:30 [Note] Slave SQL thread initialized, starting replication in log 'XX-bin.160241' at position 3547143, relay log './XX-relay-bin.003313' position: 3590153
160201 18:18:30 [Note] Slave I/O thread: connected to master 'replicate@10.16.X.X:3306',replication started in log 'XX-bin.160738' at position 8961771
19:51:48 UTC - 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=4294967296
read_buffer_size=10485760
max_used_connections=4
max_threads=8192
thread_count=3
connection_count=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 104860072 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f2ff412e7c0
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 = 7f384aa83e78 thread_stack 0x40000
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(my_print_stacktrace+0x35)[0x7a8485]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(handle_fatal_signal+0x403)[0x6758a3]
/lib64/libpthread.so.0[0x3a05e0f790]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld[0x766750]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(_Z10mysql_loadP3THDP12sql_exchangeP10TABLE_LISTR4ListI4ItemES8_S8_15enum_duplicatesbb+0x15dd)[0x76a7cd]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(_ZN14Load_log_event14do_apply_eventEP6st_netPK14Relay_log_infob+0xaf4)[0x7237c4]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(_ZN22Execute_load_log_event14do_apply_eventEPK14Relay_log_info+0x285)[0x725785]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x125)[0x5187f5]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld[0x51e465]
/opt/mysql/mysql-5.5.46-linux2.6-x86_64/bin/mysqld(handle_slave_sql+0x993)[0x51f463]
/lib64/libpthread.so.0[0x3a05e07a51]
/lib64/libc.so.6(clone+0x6d)[0x3a05ae893d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f2ff4131e08): LOAD DATA INFILE '/db/slave_tmp/SQL_LOAD-6660666-1001408088-19674.data' REPLACE INTO TABLE nctd_review FIELDS TERMINATED BY '|' ENCLOSED BY '"' ESCAPED BY '\\' LINES TERMINATED BY '\r\n' IGNORE 1 LINES  ( , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,)
Connection ID (thread ID): 377
Status: 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.

Still I couldn't repeat.