Hi,

I can crash MySQL with just the following lines :

create table t1 (col1 varchar(20) PRIMARY KEY, col2 varchar(30) not null, unique
index(col2)); insert into t1 set col1="abc", col2="Ikéa"; update t1 set col2="Ikea" where col2="Ikéa"; ERROR 2013: Lost connection to MySQL server during query

My version of MySQL is 4.1.0 and i use utf8 as default encoding. If i only put in col2 strings that are iso8859_1 equivalent (with a,b,c, ... but
not é,è, ...), i don't have the problem. If i don't put the index on col2, i also don't have the problem. The error messages in the log of mysql are below in my email.

Is this problem already known ?

Can somebody tell me if this bug will be fixed in MySQL4.1.1, and when this
version should be available ?

Thank you in advance.

Version: '4.1.0-alpha-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 031007 10:37:21 InnoDB: Assertion failure in thread 36874 in file row0upd.c
line 710 InnoDB: We intentionally generate a memory trap. InnoDB: Send a detailed bug report to mys...@lists.mysql.com 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=8388600 read_buffer_size=131072 sort_buffer_size=2097144 max_used_connections=0 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791
K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8845160 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=0xbfe7e208, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80835ca 0x82bb768 0x8169d06 0x81538b5 0x81541ee 0x816aa30 0x816b8b2 0x816baca 0x8155bf7 0x80e99cb 0x80c25e3 0x8090af6 0x8093619 0x808e3f3 0x8094be0 0x808d337 0x82b8f1c 0x82ec73a New value of fp=(nil) failed sanity check, terminating stack trace! 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 0x8841608 = update Brand3 set brandKey="Ikea" where
brandKey="Ikéa" thd->thread_id=1 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 1 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 031007 10:37:21 mysqld restarted