MySQL Bugs: #16368: InnoDB Assertion failure in file row0sel.c line 2081

Bug #16368	InnoDB Assertion failure in file row0sel.c line 2081
Submitted:	11 Jan 2006 11:32	Modified:	20 Jan 2006 15:15
Reporter:	Stephan Skusa	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.0.18	OS:	Linux (Gentoo Linux)
Assigned to:	Marko Mäkelä	CPU Architecture:	Any

Description:
060111 12:03:22InnoDB: Assertion failure in thread 278540 in file row0sel.c line 2081
InnoDB: Failing assertion: dict_col_get_type(field->col)->mtype == dfield_get_type(dfield)->mtype
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
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=16777216
read_buffer_size=258048
max_used_connections=4
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 = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8b192e8
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...
InnoDB: Thread 98311 stopped in file os0sync.c line 501
frame pointer (ebp) is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
InnoDB: Thread 114696 stopped in file ../include/sync0sync.ic line 111
thd->query at 0x8b3ca90 = SELECT sDATA FROM sessSESSIONS WHERE sID='731b357e80764c1801b5f03f0d8585a9'
thd->thread_id=7
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.
060111 12:05:30 InnoDB: Started; log sequence number 1 2277722863

How to repeat:
I don't really think that I can build a repeatable test case.
The error suddenly appeared and because it is a production system I had to recreate the used database immediatly.

Maybee the cut of the error log can be hint.

Thank you for a problem report. Is that query from the error log, SELECT sDATA FROM sessSESSIONS WHERE sID='731b357e80764c1801b5f03f0d8585a9' looks reasonable? If yes, can you, please, send the results of SHOW CREATE TABLE sess (or how it is called). You may also upload your error log (or part of it, for the appropriate period) using the File tab.

The create table statement is:

CREATE TABLE `sessSESSIONS` (
  `sID` varchar(36) collate latin1_german1_ci NOT NULL default '',
  `sDATA` longtext collate latin1_german1_ci NOT NULL,
  `sIP` int(11) unsigned NOT NULL default '0',
  `uID` int(11) unsigned default NULL,
  `sCREATED` datetime NOT NULL default '0000-00-00 00:00:00',
  `sACCESS` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`sID`),
  KEY `sCREATED` (`sCREATED`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

I hope it can help you.

How many rows are there in that sessSESSIONS table? Have you tried to CHECK it? Is it possible for you to create another InnoDB table, with the same structure and data, and try to execute the same "crashing" statement with it?

Stephan,

please attach the COMPLETE UNEDITED .err log of the server.

Have you moved .frm files around?

Regards,

Heikki

Hi!

row0sel.c:

"
/********************************************************************
Converts a key value stored in MySQL format to an Innobase dtuple. The last
field of the key value may be just a prefix of a fixed length field: hence
the parameter key_len. But currently we do not allow search keys where the
last field is only a prefix of the full key field len and print a warning if
such appears. A counterpart of this function is
ha_innobase::store_key_val_for_row() in ha_innodb.cc. */

void
row_sel_convert_mysql_key_to_innobase(
/*==================================*/
        dtuple_t*       tuple,          /* in: tuple where to build;
                                        NOTE: we assume that the type info
                                        in the tuple is already according
                                        to index! */
        byte*           buf,            /* in: buffer to use in field
                                        conversions */
        ulint           buf_len,        /* in: buffer length */
        dict_index_t*   index,          /* in: index of the key value */
        byte*           key_ptr,        /* in: MySQL key value */
        ulint           key_len,        /* in: MySQL key value length */
        trx_t*          trx)            /* in: transaction */
{
...

        while (key_ptr < key_end) {

                ut_a(dict_col_get_type(field->col)->mtype
                     == dfield_get_type(dfield)->mtype);
"

Hmm... many possible causes for this. For example, if key_len is too big.

Regards,

Heikki

The complete error log

Attachment: mysqld.err.bz2 (application/octet-stream, text), 10.83 KiB.

Now I added the complete log.

The error appeared very suddenly, without any manual modifications to the the tables structure.

Stephan,
in the error log you attached, there are quite a few assertion failures in rem0rec.c line 111 (rec_get_nth_field() being called with n==-1) as well. That leads me to suspect memory corruption, i.e., somehow the number of columns in a table becomes zero. However, that was under mysql 4.0.

There's one interesting line "InnoDB: Error: record field 1 len 4294960903" printed out by rec_validate() under 5.0.17 as well.

Has the hardware stayed the same? Would you be able to run memtest86 or other thorough memory test on the system? I would like to rule out spontaneous memory corruption caused by faulty hardware.

Also, how big is the sessSESSIONS table? Does CHECK TABLE succeed on it? What about SELECT COUNT(*) FROM sessSESSIONS?

Marko, Stephen

there are lots of these errors on Dec 22, 2005:

"
051222 22:43:50 [Warning] './artistic/tree_cat_descriptors_keywords' had no or invalid character set, and default character set is multi-byte, so character column sizes may have changed
"

And on the next day:

"
051223 17:52:25  InnoDB: Started; log sequence number 1 2041984354
051223 17:52:26 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.17'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-5.0.17
InnoDB: Error: record field 1 len 4294960903
060110 17:16:46InnoDB: Assertion failure in thread 36929549 in file row0sel.c line 2081
InnoDB: Failing assertion: dict_col_get_type(field->col)->mtype == dfield_get_type(dfield)->mtype
"

Could this explain the assertion failure?

Regards,

Heikki

The line "InnoDB: Error: record field 1 len 4294960903" in the attached error log looks very similar to Bug #16383. Still, for the other errors, I would like rule out faulty memory hardware.

22nd december should be the day i upgraded to MySQL 5.0. Gentoo sets the default charset to utf8_something which I first didn't recognized. But I changed it to latin1 (as it was before) later ... :) I don't know if this could cause the problem, but this may cause the multi-byte error message.

The sessSESSION table contained roundabout 50 records. As I thougth CHECK TABLE is just an MyISAM functionality I didn't run it before I recreated the database.

I will run a memory test later this evening, because the server is a development system which is required today. I will provide further information after the test procedure.

TIA

Stephan,
you're probably confusing the stand-alone MyISAM check tool "myisamcheck" (sp?) with the SQL command CHECK TABLE. When invoked on an InnoDB table, CHECK TABLE scans all indexes, and reports any inconsistencies it finds, e.g., records being in the wrong sorting order.

MySQL 4.0 does not store information about character sets or collations in the data dictionary. Only MySQL 4.1.2 and later do. If the server-wide default character set is changed, MySQL 4.0 tables (with keys defined on character columns) will appear corrupted. I hope you didn't write anything to such tables using the wrong default collation, because that would really corrupt the tables. However, I think that you should still be able to back up the data with mysqldump.

I'm not entirely sure if the collation mismatch can explain the assertion failures, though.

BTW, slightly off-topic note: if you have umlauts in table, index or column names, you will have to dump and reimport the database (or rename the names to ASCII) when upgrading from 4.0 to 4.1 or later. MySQL 4.1 and later encode the names in UTF-8, while you most likely used latin1 in MySQL 4.0.

Stephan,
Any news?

Yes sorry, memtest86 ran for two days without showing any errors.

A check table is not possible anymore because, as I stated before, the database has been rebuild meanwhile.

But I did several check tables on other databases running on this server without show any errors.

PS.: As a "good coder" :) I never use "umlauts" in any object names neither in programming languages nor in database objects ...

I would suspect that the assertion failure was caused by the missing collation information in the tables created in MySQL 4.0 combined with the changed default collation. But we will sadly never know it, as you rebuilt the database.

I know ... and i could bite me into the ... (let's drop it) ...

But in fact some days ago I had a very similar problem executing "SELECT COUNT(*) AS num FROM `information_schema`.`KEY_COLUMN_USAGE`" ... btw. phpMyAdmin had this problem ... not me ... but KEY_COLUMN_USAGE is not an innodb table ... !

Maybe I should attache the error log ... !

Oh sorry ... this maybe should be another thread ... it's an completely other error  ....

Stephan,

please search the bug database if that information schema problem has been reported yet. If not, open another bug report about that information schema problem.

Regards,

Heikki