Mauricio, " 040901 18:45:26 InnoDB: Assertion failure in thread 11272203 in file row0upd.c line 713 InnoDB: Failing assertion: len == dfield_get_len(dfield) "
It might this bug that was fixed in 4.1.2: " Fixed a bug: If you created a column prefix secondary index and updated it so that the last characters in the column prefix were spaces, InnoDB would assert in `row0upd.c', line 713. The same assertion failed if you updated a column in an ordinary secondary index so that the new value was alphabetically equivalent, but had a different length. This could happen, for example, in the UTF8 character set if you updated a letter to its accented or umlaut form. " I am afraid that the involved table(s) may now be corrupt. You may need to dump and recreate them. If you upgrade to 4.1.4, please observe the following: " Important: If you have created or used InnoDB tables with TIMESTAMP columns in MySQL versions 4.1.0 - 4.1.3, you have to rebuild those tables when you upgrade to MySQL-4.1.4 or later. The storage format in those MySQL versions for a TIMESTAMP column was wrong. If you upgrade from 4.0 to 4.1.4 or later, then no rebuild of TIMESTAMP tables is needed. Important: If you have stored characters < ASCII(32) to non-latin1 non-BINARY indexed columns in MySQL versions <= 4.1.2, then you have to rebuild those tables after you upgrade to >= 4.1.3. The reason is that the sorting order of those characters and the space character changes for some character sets in 4.1.3. See the MySQL/InnoDB-4.1.3 changelog for a precise description of the cases where you need to rebuild the table. " Best regards, Heikki Innobase Oy InnoDB - transactions, row level locking, and foreign keys for MySQL InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables http://www.innodb.com/order.php Order MySQL support from http://www.mysql.com/support/index.html ----- Alkuperäinen viesti ----- Lähettäjä: "Mauricio Pellegrini" <[EMAIL PROTECTED]> Vastaanottaja: "Heikki Tuuri" <[EMAIL PROTECTED]> Lähetetty: Friday, September 03, 2004 1:42 AM Aihe: Re: Query hangs mysql 4.1 > Hi, the file is compressed and attached > Thank you > Mauricio > > On Thu, 2004-09-02 at 10:34, Heikki Tuuri wrote: > > Mauricio, > > > > please send the FULL .err log to me. Do not cut anything off. > > > > [EMAIL PROTECTED] > > > > Best regards, > > > > Heikki > > Innobase Oy > > InnoDB - transactions, row level locking, and foreign keys for MySQL > > InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM > > tables > > http://www.innodb.com/order.php > > > > Order MySQL support from http://www.mysql.com/support/index.html > > > > .................... > > Hi, > > I've experienced a hang after running a query wich is run usually 2 to 3 > > times a day without a problem till now. > > > > This is what the error log reports > > > > nnoDB: Thread 4784139 stopped in file btr0pcur.c line 205 > > 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=0xbe3fddb8, backtrace may not be correct. > > Stack range sanity check OK, backtrace follows: > > 0x8108af7 > > 0x4014c895 > > 0x8280a88 > > 0x82630ba > > 0x82694eb > > 0x82697a1 > > 0x82818f0 > > 0x8282495 > > 0x828267a > > 0x826b7bc > > 0x817abf3 > > 0x814edf1 > > 0x814ef81 > > 0x81401e2 > > 0x8137049 > > 0x8137585 > > 0x814e061 > > 0x8118164 > > 0x811b121 > > 0x811552f > > 0x8114ec2 > > 0x8114637 > > 0x40146c60 > > 0x402e9b77 > > New value of fp=(nil) failed sanity check, terminating stack trace! > > > > Also have part of the query in the log. and some other warnings about > > the memory bee used acording to the defined variables. > > > > I've used resolve_stack_dump -s /usr/lib/mysql/mysqld-max.sym -n > > mysqld.stack > > as instructed in the manual, with the following result > > > > 0x8108af7 handle_segfault + 423 > > 0x4014c895 _end + 934924901 > > 0x8280a88 row_upd_build_sec_rec_difference_binary + 408 > > 0x82630ba row_ins_sec_index_entry_by_modify + 90 > > 0x82694eb row_ins_index_entry_low + 2859 > > 0x82697a1 row_ins_index_entry + 65 > > 0x82818f0 row_upd_sec_index_entry + 848 > > 0x8282495 row_upd + 197 > > 0x828267a row_upd_step + 282 > > 0x826b7bc row_update_for_mysql + 700 > > 0x817abf3 update_row__11ha_innobasePCcPc + 291 > > 0x814edf1 do_updates__12multi_updateb + 465 > > 0x814ef81 send_eof__12multi_update + 49 > > 0x81401e2 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 530 > > 0x8137049 exec__4JOIN + 4185 > > 0x8137585 > > mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_ord > > erT7T5T7Ul \ > > P13select_resultP18st_select_lex_unitP13s + 837 0x814e061 > > mysql_multi_update__FP3THDP13st_table_listPt4List1Z4ItemT2P4ItemUl15enum_dup > > licatesP18 \ > > st_select_lex_unitP13st_select_lex + 369 0x8118164 > > mysql_execute_command__FP3THD + \ > > 7780 0x811b121 mysql_parse__FP3THDPcUi + 177 > > 0x811552f dispatch_command__F19enum_server_commandP3THDPcUi + 1631 > > 0x8114ec2 do_command__FP3THD + 162 > > 0x8114637 handle_one_connection + 551 > > 0x40146c60 _end + 934901296 > > 0x402e9b77 _end + 936617287 > > > > Watching those entries in the error log I cant figure why is this > > happening. Can anybody give me a hint? > > > > Thank you > > Mauricio > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
