MySQL Bugs: #3690: REPLACE sql statement causes crash

Bug #3690	REPLACE sql statement causes crash
Submitted:	7 May 2004 21:28	Modified:	7 May 2004 21:42
Reporter:	Nick Sullivan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.1.1-alpha-max-log	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
I have duplicatable crash for mysql, when a particular "replace" sql statement is executed.

REPLACE INTO ctextdeps SET
        textid='1',
        scriptType='vortex',
        scriptPath='/texis/productsBanner'

Here's the create table statement for the ctextdeps table:
CREATE TABLE `ctextdeps` (
  `textid` smallint(5) unsigned NOT NULL default '0',
  `depDate` timestamp NOT NULL,
  `scriptType` varchar(10) default NULL,
  `scriptPath` varchar(100) default NULL,
  UNIQUE KEY `textid` (`textid`,`scriptPath`(14))
) TYPE=InnoDB DEFAULT CHARSET=utf8;

In hindsight, "INSERT IGNORE" is more appropriate than REPLACE, but I wanted to report the crash anyway. "INSERT IGNORE" is a valid workaround.

The above 

Version: '4.1.1-alpha-max-log'  socket: '/tmp/mysql.sock'  port: 3306
040507 12:05:11  Slave I/O thread: connected to master 'repl@roll:3306',  replication started in log 'roll-bin.000005' at position 278826500
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=268435456
read_buffer_size=2093056
max_used_connections=2
max_connections=1500
threads_connected=3
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2205828 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x86a9470
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=0x5ad2fc68, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8106af3
0x4003c7ce
0x4207da1c
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x86cb3e0 = REPLACE INTO ctextdeps SET
        textid='1',
        scriptType='vortex',
        scriptPath='/texis/productsBanner'
thd->thread_id=5
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
040507 12:05:22  mysqld restarted...

How to repeat:
CREATE TABLE `ctextdeps` (
  `textid` smallint(5) unsigned NOT NULL default '0',
  `depDate` timestamp NOT NULL,
  `scriptType` varchar(10) default NULL,
  `scriptPath` varchar(100) default NULL,
  UNIQUE KEY `textid` (`textid`,`scriptPath`)
) TYPE=InnoDB;

INSERT INTO ctextdeps SET
        textid='1',
        scriptType='vortex',
        scriptPath='/texis/productsBanner';

REPLACE INTO ctextdeps SET
        textid='1',
        scriptType='vortex',
        scriptPath='/texis/productsBanner';

-- mysql will crash here...
-- message is ERROR 2013 (HY000): Lost connection to MySQL server during query

Thank you for the bug report, this issue was already fixed
on the current BK tree.

mysql> CREATE TABLE `ctextdeps` (
    ->   `textid` smallint(5) unsigned NOT NULL default '0',
    ->   `depDate` timestamp NOT NULL,
    ->   `scriptType` varchar(10) default NULL,
    ->   `scriptPath` varchar(100) default NULL,
    ->   UNIQUE KEY `textid` (`textid`,`scriptPath`)
    -> ) TYPE=InnoDB;
Query OK, 0 rows affected, 2 warnings (0.08 sec)

mysql> INSERT INTO ctextdeps SET
    ->         textid='1',
    ->         scriptType='vortex',
    ->         scriptPath='/texis/productsBanner';
Query OK, 1 row affected (0.01 sec)

mysql> REPLACE INTO ctextdeps SET
    ->         textid='1',
    ->         scriptType='vortex',
    ->         scriptPath='/texis/productsBanner';
Query OK, 2 rows affected (0.00 sec)