Bug with utf8 ?

------=_NextPart_000_03C4_01C38CC4.266815A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi,

I can crash MySQL with just the following lines :=20

create table t1 (col1 varchar(20) PRIMARY KEY, col2 varchar(30) not =
null, unique index(col2));
insert into t1 set col1=3D"abc", col2=3D"Ik=E9a";
update t1 set col2=3D"Ikea" where col2=3D"Ik=E9a";
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
=E9,=E8, ...), 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 mysql@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=3D8388600
read_buffer_size=3D131072
sort_buffer_size=3D2097144
max_used_connections=3D0
max_connections=3D100
threads_connected=3D1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =
=3D 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=3D0x8845160
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=3D0xbfe7e208, 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=3D(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 =3D update Brand3 set brandKey=3D"Ikea" where =
brandKey=3D"Ik=E9a"
thd->thread_id=3D1
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




------=_NextPart_000_03C4_01C38CC4.266815A0--

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 mysql@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


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug with utf8 ?

Bertrand,

I still cannot repeat it.

[mysqld]
language=/home/heikki/mysql-standard-4.1.0-alpha-pc-linux-i6 86/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



Regards,

Heikki

----- Alkuperäinen viesti -----
Lähettäjä: "Bertrand Lanneau"
Vastaanottaja: "Heikki Tuuri"
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"
> To:
> 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 mysql@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
> >
> >
> > --
> > MySQL Bugs Mailing List
> > For list archives: http://lists.mysql.com/bugs
> > To unsubscribe:
> http://lists.mysql.com/bugs?unsub=bertrand.lanneau@citobi.be
> >
> >
>
>


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Bug with utf8 ?

----- Original Message -----
From: "Heikki Tuuri"
To:
Sent: Friday, October 10, 2003 12:10 PM
Subject: Re: Bug with utf8 ?


> Resending, because email bounced.
>
> ----- Original Message -----
> From: "Heikki Tuuri"
> To: "Bertrand Lanneau"
> Cc:
> Sent: Friday, October 10, 2003 12:07 PM
> Subject: Re: Bug with utf8 ?
>
>
> > Bertrand,
> >
> > I think I know why you are getting the assertion failure while I am not.
> >
> > In your computer é is probably coded as two characters while in my
> computer
> > it is coded as one character. The sort function considers é equal to e
in
> > both computers. But InnoDB assumes that two equal strings are always
equal
> > in length, too! That explains why the assertion fails.
> >
> > I have to modify the algorithm in 4.1, so that it is prepared for the
case
> > where the sort ordering considers two strings equal though they are not
> > equal in length.
> >
> > Best regards,
> >
> > Heikki Tuuri
> > Innobase Oy
> > http://www.innodb.com
> > Foreign keys, transactions, and row level locking for MySQL
> > InnoDB Hot Backup - a hot backup tool for MySQL
> >
> > Order MySQL technical support from https://order.mysql.com/
> >
> >
> >
> > /*********************************************************** ************
> > Does an insert operation by updating a delete-marked existing record
> > in the index. This situation can occur if the delete-marked record is
> > kept in the index for consistent reads. */
> > static
> > ulint
> > row_ins_sec_index_entry_by_modify(
> > /*==============================*/
> > /* out: DB_SUCCESS or error code */
> > btr_cur_t* cursor, /* in: B-tree cursor */
> > dtuple_t* entry, /* in: index entry to insert */
> > que_thr_t* thr, /* in: query thread */
> > mtr_t* mtr) /* in: mtr */
> > {
> > mem_heap_t* heap;
> > upd_t* update;
> > rec_t* rec;
> > ulint err;
> >
> > rec = btr_cur_get_rec(cursor);
> >
> > ut_ad((cursor->index->type & DICT_CLUSTERED) == 0);
> > ut_ad(rec_get_deleted_flag(rec));
> >
> > /* We know that in the alphabetical ordering, entry and rec are
> > identical. But in their binary form there may be differences if
> > there are char fields in them. Therefore we have to calculate
the
> > difference and do an update-in-place if necessary. */
> >
> > heap = mem_heap_create(1024);
> >
> > update = row_upd_build_sec_rec_difference_binary(cursor->index,
> > entry, rec,
heap);
> >
> > err = btr_cur_update_sec_rec_in_place(cursor, update, thr, mtr);
> >
> > mem_heap_free(heap);
> > }
> >
> > ----- Original Message -----
> > From: "Bertrand Lanneau"
> > To: "Heikki Tuuri"
> > Sent: Friday, October 10, 2003 10:47 AM
> > Subject: Re: Bug with utf8 ?
> >
> >
> > >
> > > Heikki,
> > >
> > > I don't use any foreign key and i am sure i can repeat it with just
> > > the 3 lines tht i have given.
> > >
> > > I reproduced it again this morning with the same 3 lines,
> > > and resolved the stack trace as you asked it.
> > >
> > > Here are the result of the stack trace, followed by the log,
> > > where the request that crach mysql is
> > > query at 0x8841608 = update t1 set col2="Ikea" where col2="Ikéa"
> > >
> > > I hope it can help.
> > >
> > >
> > > 0x80835ca handle_segfault + 450
> > > 0x82bb768 pthread_sighandler + 184
> > > 0x8169d06 row_upd_build_sec_rec_difference_binary + 422
> > > 0x81538b5 row_ins_index_entry_low + 1541
> > > 0x81541ee row_ins_index_entry + 214
> > > 0x816aa30 row_upd_sec_index_entry + 1084
> > > 0x816b8b2 row_upd + 398
> > > 0x816baca row_upd_step + 326
> > > 0x8155bf7 row_update_for_mysql + 731
> > > 0x80e99cb update_row__11ha_innobasePCcPc + 535
> > > 0x80c25e3
> > >
> >
>
mysql_update__FP3THDP13st_table_listRt4List1Z4ItemT2P4ItemUi P8st_orderUl15en
> > > um_duplicates + 2819
> > > 0x8090af6 mysql_execute_command__FP3THD + 6754
> > > 0x8093619 mysql_parse__FP3THDPcUi + 377
> > > 0x808e3f3 dispatch_command__F19enum_server_commandP3THDPcUi + 2143
> > > 0x8094be0 do_command__FP3THD + 156
> > > 0x808d337 handle_one_connection + 599
> > > 0x82b8f1c pthread_start_thread + 220
> > > 0x82ec73a thread_start + 4
> > >
> > >
> > >
> > >
> > >
> > > /usr/sbin/mysqld: ready for connections.
> > > Version: '4.1.0-alpha-log' socket: '/var/lib/mysql/mysql.sock' port:
> > 3306
> > > 031010 9:35:16 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 mysql@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=1
> > > 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 t1 set col2="Ikea" where col2="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.
> > >
> > >
> > >
> > >
> > > Bertrand;
> > >
> > >
> >
>



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org