MySQL Bugs: #71649: Executing multiple REPLACE statements causes connection to be lost

Bug #71649	Executing multiple REPLACE statements causes connection to be lost
Submitted:	10 Feb 2014 9:50	Modified:	8 Jun 2014 22:09
Reporter:	Anthony Marston	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S2 (Serious)
Version:	5.6.16	OS:	Windows (Windows 7 64 bit)
Assigned to:		CPU Architecture:	Any
Tags:	Lost connection, REPLACE

Description:
I am trying to move data from one server to another, for which I have created a script containing 24,500 REPLACE INTO statements. When I run this on version 5.6.6 it produces the following error:

SQL error (2013): Lost connection to MySQL server during query

It also kills the process so I have to restart it.

When I run the same query on a different server with version 5.6.15 it executes perfectly.

I have tried running this query through HeidiSQL, SQLyog and phpMyadmin with the same results.

How to repeat:
Create a query with 24,500 replace (or insert) statements, and try to execute that query.

Thank you for the bug report. Please provide the err log?. Thanks.

This is from the error log:

2014-02-10 13:39:14 5520 [Note] Plugin 'FEDERATED' is disabled.
2014-02-10 13:39:14 5520 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2014-02-10 13:39:14 5520 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-02-10 13:39:14 5520 [Note] InnoDB: The InnoDB memory heap is disabled
2014-02-10 13:39:14 5520 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2014-02-10 13:39:14 5520 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-02-10 13:39:14 5520 [Note] InnoDB: Not using CPU crc32 instructions
2014-02-10 13:39:14 5520 [Note] InnoDB: Initializing buffer pool, size = 280.0M
2014-02-10 13:39:14 5520 [Note] InnoDB: Completed initialization of buffer pool
2014-02-10 13:39:14 5520 [Note] InnoDB: Highest supported file format is Barracuda.
2014-02-10 13:39:16 5520 [Note] InnoDB: 128 rollback segment(s) are active.
2014-02-10 13:39:16 5520 [Note] InnoDB: Waiting for purge to start
2014-02-10 13:39:16 5520 [Note] InnoDB: 5.6.16 started; log sequence number 10415747537
2014-02-10 13:39:17 5520 [Note] Server hostname (bind-address): '*'; port: 3306
2014-02-10 13:39:17 5520 [Note] IPv6 is available.
2014-02-10 13:39:17 5520 [Note]   - '::' resolves to '::';
2014-02-10 13:39:17 5520 [Note] Server socket created on IP: '::'.
2014-02-10 13:39:17 5520 [Note] Event Scheduler: Loaded 0 events
2014-02-10 13:39:17 5520 [Note] C:/Program Files/MySQL/MySQL Server 5.6/bin\mysqld: ready for connections.
Version: '5.6.16-log'  socket: ''  port: 3306  MySQL Community Server (GPL)
2014-02-10 13:39:36 1e58  InnoDB: Assertion failure in thread 7768 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.

InnoDB: Failing assertion: sym_node->table != NULL

1)  are these innodb fulltext tables?
2)  did you move physical files from windows to linux or vise versa?

Yes, the table has a FULLTEXT index.
No, I did not move the physical files from Linux to Windows or vice versa.

Please try version 5.6.19. Thanks.

I cannot reproduce this problem in version 5.6.19, so I'll consider it fixed.