Re: Bug with utf8 ?

Bertrand,

I am not able to crash 4.1.0-alpha with the my.cnf below. What is your
my.cnf like?

Regards,

Heikki


heikki@hundin:~/mysql-4.1b/client> mysql test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.0-alpha-standard-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> create table t1 (col1 varchar(20) PRIMARY KEY, col2 varchar(30) not
null,
 unique index(col2));
Query OK, 0 rows affected (0.05 sec)

mysql> insert into t1 set col1="abc", col2="Ikéa";
Query OK, 1 row affected (0.03 sec)

mysql> update t1 set col2="Ikea" where col2="Ikéa";
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql>

# The MySQL server
[mysqld]
#set-variable = lower_case_table_names=1
#bdb-no-sync
set-variable = query_cache_size=10M
set-variable = query_cache_type=1
#skip-innodb
server-id=1
language=/home/heikki/mysql-4.1b/sql/share/english
default-table-type=innodb
log-bin=binlog
set-variable = max_binlog_size=20M
port=3307
socket=/home/heikki/MySQLheikki
skip-locking
default-character-set=utf8

basedir=/home/heikki
datadir=/home/heikki/data

#set-variable=lower_case_table_names=1

#set-variable    = table_cache=1000
set-variable    = max_connections=1000
#set-variable    = sort_buffer=1M
#set-variable    = record_buffer=1M
set-variable    = max_allowed_packet=30M
#set-variable    = thread_stack=256K
set-variable    = key_buffer=1M
#set-variable = flush_time=1800
#transaction-isolation = READ-COMMITTED
#innodb_file_per_table
#innodb_open_files=765
innodb_data_home_dir =  /home/heikki/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir=/home/heikki/data
innodb_log_arch_dir=/home/heikki/data
set-variable =innodb_log_files_in_group=2
set-variable = innodb_log_file_size=5M
set-variable = innodb_log_buffer_size=512k
innodb_flush_log_at_trx_commit=0
set-variable = innodb_buffer_pool_size=12M
#set-variable = innodb_buffer_pool_awe_mem_mb=100
set-variable = innodb_additional_mem_pool_size=512k
#set-variable = innodb_lock_wait_timeout=5
#innodb_force_recovery=4
#set-variable = innodb_thread_concurrency=8
#innodb_flush_method=fdatasync
#innodb_fast_shutdown=0

# Uncomment the following row if you move the MySQL distribution to another
# location
#basedir = d:/mysql/

[mysqldump]
quick
set-variable = max_allowed_packet=16M

[mysql]
no-auto-rehash
socket=/home/heikki/MySQLheikki
#socket=/tmp/mysqld.heikki
port=3307

[mysqladmin]
socket=/home/heikki/MySQLheikki
#socket=/tmp/mysqld.heikki
port=3307

[isamchk]
set-variable= key=16M

[client_fltk]



List: MySQL Bugs « Previous Message Next Message »
From: Bertrand Lanneau Date: October 7 2003 11:14am
Subject: Bug with utf8 ?



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.

Bertrand Lanneau.



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 [email protected]
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


-- 
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe:    http://lists.mysql.com/[email protected]