Bug #6633 InnoDB crashes when converting table from MyISAM to InnoDB
Submitted: 15 Nov 2004 11:41 Modified: 30 Nov 2004 16:24
Reporter: jocelyn fournier (Silver Quality Contributor) Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: InnoDB storage engine Severity:S1 (Critical)
Version:4.1.8 bktree OS:Linux (Linux)
Assigned to: Marko Mäkelä CPU Architecture:Any

[15 Nov 2004 11:41] jocelyn fournier

When trying to convert a MyISAM table to InnoDB, InnoDB crashes :

InnoDB: Assertion failure in thread 1785966 in file lock0lock.c line 407
InnoDB: Failing assertion: lock->type_mode == (LOCK_TABLE | LOCK_IX)

I encountered this crash when trying to create a bug report for this one : 
initially my table was in InnoDB format and when trying to change one column, InnoDB crashes :

ALTER TABLE inscrit2 CHANGE password_key password_key varchar(20) binary NULL;

InnoDB: Assertion failure in thread 1097796 in file ha_innodb.cc line 2327
InnoDB: Failing assertion: prebuilt->trx->mysql_n_tables_locked == 2

Don't know if it's the same bug.


How to repeat:


Then execute :


For bug n°2, when table is in InnoDB format :

ALTER TABLE inscrit2 CHANGE password_key password_key varchar(20) binary NULL;
[15 Nov 2004 13:06] Marko Mäkelä
Hi Jocelyn,
Many thanks for your report. The bugs are most likely caused by my patch to ALTER TABLE, so that it would commit the inserts to the temporary table after every 10,000 rows. The logic only accounts for the case when the table already is in InnoDB format, and I didn't test the conversion from MyISAM to InnoDB. My bad.
[15 Nov 2004 13:13] jocelyn fournier
Hi Marko,

So the second bug is probably not related to the first one ? (since for the second crash, the table was already in InnoDB format).

Thanks !
[15 Nov 2004 13:41] Heikki Tuuri

only put

fprintf(stderr, ...)

instead of ut_a(...), if the error is not absolutely fatal.

We cannot test all types of ALTER TABLE, and what is MySQL's lock behavior in them.


[15 Nov 2004 14:26] Marko Mäkelä
Both assertion failures are related to my ALTER TABLE modification. I've now committed a fix to the assertion failure in ha_innodb.cc. Next, I'll try to reproduce the second failure with your test case.
[15 Nov 2004 15:01] Marko Mäkelä
I was able to reproduce the assertion failure with your test data in lock_get_ix_table(), even after my fix to ha_innodb.cc applied. I'll make another patch tomorrow.
[26 Nov 2004 23:22] Marko Mäkelä
I'm sorry for the delay; I had to work on other things.
I've now pushed a fix that corrects both problems exposed by your test case. ALTER TABLE from other engine to InnoDB caused an assertion failure. Also, ALTER TABLE or OPTIMIZE TABLE will no longer attempt to commit after every 10,000 rows if the table is originally in InnoDB format, and there are other locks than a single IX or IS lock on it. This means that the intermediate commits are disabled for tables containing an auto_increment field.
[30 Nov 2004 16:24] Marko Mäkelä
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

Additional info:

I made a better fix that allows intermediate commits for tables containing auto_increment columns, and pushed it to the 4.1 tree.
[16 Jan 2009 9:41] Marko Mäkelä
See also Bug #42152.