Re: Bug with utf8 ?

----- Original Message ----- 
From: "Heikki Tuuri" <[email protected]>
To: <[email protected]>
Sent: Friday, October 10, 2003 12:10 PM
Subject: Re: Bug with utf8 ?


> Resending, because email bounced.
>
> ----- Original Message ----- 
> From: "Heikki Tuuri" <[email protected]>
> To: "Bertrand Lanneau" <[email protected]>
> Cc: <[email protected]>
> 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" <[email protected]>
> > To: "Heikki Tuuri" <[email protected]>
> > 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_listRt4List1Z4ItemT2P4ItemUiP8st_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 [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=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/[email protected]