MySQL Bugs: #9526: ENUM storage wrong; Got signal 11 when trying to create an InnoDB table

Bug #9526	ENUM storage wrong; Got signal 11 when trying to create an InnoDB table
Submitted:	31 Mar 2005 14:39	Modified:	18 May 2005 16:09
Reporter:	Marcos Araujo	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	standard 5.0.3 beta	OS:	Linux (Debian Linux - Kernel 2.6.7-1-k7)
Assigned to:	Marko Mäkelä	CPU Architecture:	Any

Description:
I'm trying the new MySQL 5.0.3 and I'm having *a lot* of trouble.

I have 2 "old" databases: one with only MyISAM tables, that is working fine under 5.0.3 and a new database with a lot of InnoDB tables with foreign keys.

Every time that I try to restore my sql dump I got this error, every time on the same table.

I will try to compile the sourcecode by myself but I think that it's a real bug.

050331 11:36:42InnoDB: Assertion failure in thread 53259 in file ../include/data0type.ic line 466
InnoDB: Failing assertion: type->len % type->mbmaxlen == 0
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=8388600
read_buffer_size=131072
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=0x89beb68
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=0xbfe59348, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8097bf3
0x8338788
0x817d7e7
0x817f47b
0x819a60e
0x81b6d2d
0x812a562
0x812ab42
0x8120e63
0x810d11b
0x8132863
0x80a95c7
0x80ae3cf
0x80a6f44
0x80a68af
0x80a5e64
0x8335f3c
0x835f94a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/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 0x89bca58 = CREATE TABLE `CalendarAccess` (
`ViewerId` mediumint(8) unsigned NOT NULL default '0',
`OwnerId` mediumint(8) unsigned NOT NULL default '0',
`AccessType` enum('r','rw') NOT NULL default 'r',
`DateCreated` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY (`ViewerId`,`OwnerId`),
KEY `ViewerId` (`ViewerId`),
KEY `OwnerId` (`OwnerId`)
) ENGINE=InnoDB
thd->thread_id=4
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.

Number of processes running now: 0
050331 11:36:42 mysqld restarted
050331 11:36:42 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
050331 11:36:42 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 304414.
InnoDB: Doing recovery: scanned up to log sequence number 0 304414
050331 11:36:42 InnoDB: Started; log sequence number 0 304414
050331 11:36:42 InnoDB: Starting recovery for XA transactions...
050331 11:36:42 InnoDB: 0 transactions in prepared state after recovery
050331 11:36:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.0.3-beta-standard' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL)

How to repeat:
CREATE DATABASE CRM2;
CREATE TABLE `CalendarAccess` (
`ViewerId` mediumint( 8 ) unsigned NOT NULL default '0',
`OwnerId` mediumint( 8 ) unsigned NOT NULL default '0',
`AccessType` enum( 'r', 'rw' ) NOT NULL default 'r',
`DateCreated` datetime NOT NULL default '0000-00-00 00:00:00',
PRIMARY KEY ( `ViewerId` , `OwnerId` ) ,
KEY `ViewerId` ( `ViewerId` ) ,
KEY `OwnerId` ( `OwnerId` )
) ENGINE = InnoDB

Suggested fix:
No idea

I wasn't able to repeat,most probably testing with the dump file
is possible to find the crash.

I wasn't able to get the same results by executing your create table statment:

mysql>  CREATE TABLE `CalendarAccess` (
    -> `ViewerId` mediumint( 8 ) unsigned NOT NULL default '0',
    -> `OwnerId` mediumint( 8 ) unsigned NOT NULL default '0',
    -> `AccessType` enum( 'r', 'rw' ) NOT NULL default 'r',
    -> `DateCreated` datetime NOT NULL default '0000-00-00 00:00:00',
    -> PRIMARY KEY ( `ViewerId` , `OwnerId` ) ,
    -> KEY `ViewerId` ( `ViewerId` ) ,
    -> KEY `OwnerId` ( `OwnerId` )
    -> ) ENGINE = InnoDB 
    -> ;
Query OK, 0 rows affected (0.00 sec)

mysql>

Hi!

What is your my.cnf like?

Are you using the UTF-8 charset?

I guess that the following may trigger the assertion failure, because of a newly discovered bug in storing ENUMs in InnoDB:

`AccessType` enum('r','rw') NOT NULL default 'r',

Maybe Marko should remove the assertion from InnoDB, because it does not work right for ENUMs currently?

I will fix the ENUM storage soon.

Regards,

Heikki

Yes, I'm using UTF-8.

SQL Dump

Attachment: CRM2_Create_Table.sql (text/x-sql), 70.82 KiB.

I've uploaded the sql dump, so you can test it better.
Cheers

Thank you. Marko will remove the assertion, if necessary, and I will change the internal type of ENUM to an unsigned integer inside InnoDB. I have to check field->real_type() in ha_innodb.cc instead of field->type().

Regards,

Heikki

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23628

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23630

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23632

I have now pushed the fix to 4.1 and 5.0. I will probably not fix 4.0 at all.

Regards,

Heikki

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/23665

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html