Re: Bug with utf8 ?

Bertrand,

I still cannot repeat it.

[mysqld]
language=/home/heikki/mysql-standard-4.1.0-alpha-pc-linux-i686/share/mysql/e
ngl\
ish
datadir=/home/heikki/data
basedir=/home/heikki
port=3307
socket=/home/heikki/MySQLheikki
server-id=1
default-table-type=innodb
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
log-bin=/home/heikki/data
log-slow-queries=/home/heikki/data/slow
long-query-time=3
default-character-set=utf8

[mysql]
port=3307
socket=/home/heikki/MySQLheikki

[mysqladmin]
port=3307
socket=/home/heikki/MySQLheikki


heikki@hundin:~/mysql-standard-4.1.0-alpha-pc-linux-i686/bin> mysql test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

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> drop table t1;
Query OK, 0 rows affected (0.00 sec)

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

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

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

mysql>



/*******************************************************************
Builds an update vector from those fields which in a secondary index entry
differ from a record that has the equal ordering fields. NOTE: we compare
the fields as binary strings! */

upd_t*
row_upd_build_sec_rec_difference_binary(
/*====================================*/
                                /* out, own: update vector of differing
                                fields */
        dict_index_t*   index,  /* in: index */
        dtuple_t*       entry,  /* in: entry to insert */
        rec_t*          rec,    /* in: secondary index record */
        mem_heap_t*     heap)   /* in: memory heap from which allocated */
{
        upd_field_t*    upd_field;
        dfield_t*       dfield;
        byte*           data;
        ulint           len;
        upd_t*          update;
        ulint           n_diff;
        ulint           i;

        /* This function is used only for a secondary index */
        ut_ad(0 == (index->type & DICT_CLUSTERED));

        update = upd_create(dtuple_get_n_fields(entry), heap);

        n_diff = 0;

        for (i = 0; i < dtuple_get_n_fields(entry); i++) {

                data = rec_get_nth_field(rec, i, &len);

                dfield = dtuple_get_nth_field(entry, i);

                ut_a(len == dfield_get_len(dfield));


It is the assertion above which fails.

The crash below says that the query is:

> > thd->query at 0x8841608 = update Brand3 set brandKey="Ikea" where
> > brandKey="Ikéa"

Are you sure that also the simple SQL command sequence you gave crashes
mysqld? If you start from a fresh clean installation of MySQL-4.1.0, can you
repeat the crash?

Actually, I guess that you are using FOREIGN KEYs, and the bug you have
encountered is one of these:

"
MySQL/InnoDB-4.0.14, July 21, 2003
...
Fixed a bug: if in a FOREIGN KEY with an UPDATE CASCADE clause the parent
column was of a different internal storage length than the child column,
then a cascaded update would make the column length wrong in the child table
and corrupt the child table. Because of MySQL's 'silent column specification
changes' a fixed-length CHAR column can change internally to a VARCHAR and
cause this error.

Fixed a bug: if a non-latin1 character set was used and if in a FOREIGN KEY
the parent column was of a different internal storage length than the child
column, then all inserts to the child table would fail in a foreign key
error.
"

Please resolve the stack trace below with

resolve_stack_dump mysqld.sym
<paste the trace here>


Regards,

Heikki

----- Alkuperäinen viesti ----- 
Lähettäjä: "Bertrand Lanneau" <[email protected]>
Vastaanottaja: "Heikki Tuuri" <[email protected]>
Lähetetty: Thursday, October 09, 2003 7:22 PM
Aihe: Re: Bug with utf8 ?


>
> Heikki,
>
> Thanks for looking at the problem.
> The my.cnf that i use is below.
> I use innodb tables and run on Linux RedHat 8.0
>
>
> [mysqld]
> server-id=1
> default-table-type=innodb
> innodb_data_home_dir = /mnt/data/citobiSite/db/innodb/
> innodb_data_file_path = ibdata1:10M:autoextend
> innodb_log_group_home_dir = /mnt/data/citobiSite/db/innodb/
> innodb_log_arch_dir = /mnt/data/citobiSite/db/innodb/
> log-bin=/mnt/data/citobiSite/db/avel-binlog
> log-slow-queries=/mnt/data/citobiSite/db/avel-slow
> long-query-time=3
> default-character-set=utf8
>
>
>
> Bertrand.
>
>
>
>
> ----- Original Message -----
> From: "Heikki Tuuri" <[email protected]>
> To: <[email protected]>
> Sent: Thursday, October 09, 2003 3:00 PM
> Subject: 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]
> >
> >
>
>


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