MySQL Bugs: #36169: create innodb compressed table with too large row size crashed

Bug #36169	create innodb compressed table with too large row size crashed
Submitted:	17 Apr 2008 7:22	Modified:	18 Jun 2010 23:01
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S1 (Critical)
Version:	innodb_plugin-1.0.0, standard innodb in 5.1	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
I built the innodb_plugin-1.0.0-5.1 on windows, with 5.1.25 bk source, and ran some tests. one of the create tables crashed with stack trace:

mysqld.exe!strchr
mysqld.exe!row_drop_table_for_mysql_no_commit
mysqld.exe!row_create_index_for_mysql
mysqld.exe!create_index
mysqld.exe!ha_innobase::create
mysqld.exe!ha_create_table
mysqld.exe!rea_create_table
mysqld.exe!mysql_create_table_no_lock
mysqld.exe!mysql_create_table
mysqld.exe!mysql_execute_command

Re-running the create table didn't crash, but instead gave this error:

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. You have to change some columns to TEXT or BLOBs

How to repeat:
I'll see how this happened and make a testcase.

full stack in file to avoid untidy wrapping.

Attachment: bug36169_stack_trace.txt (text/plain), 2.00 KiB.

10 tables to import. create table table6 causes a crash..

Attachment: bug36169.sql (application/unknown, text), 35.66 KiB.

in row_create_index_for_mysql, the error_handling: code in invoked.
then, row_drop_table_for_mysql(index->table_name, trx, FALSE); is called but index struct members have bogus/uninitialized values:

index	0x0bf26800 {id={...} heap=0xfeeefeee name=0xfeeefeee <Bad Ptr> ...}	dict_index_struct *
id	{high=4277075694 low=4277075694 }	dulint_struct
heap	0xfeeefeee {magic_n=??? file_name=0xfeeefef2 <Bad Ptr> line=??? ...}	mem_block_info_struct *
name	0xfeeefeee <Bad Ptr>	const char *
table_name	0xfeeefeee <Bad Ptr>	const char *
table	0xfeeefeee {id={...} heap=??? name=??? ...}	dict_table_struct *
space	4277075694	unsigned int
page	4277075694	unsigned int
type	14	unsigned int
trx_id_offset	1006	unsigned int
n_user_defined_cols	955	unsigned int
n_uniq	750	unsigned int
n_def	959	unsigned int
n_fields	1006	unsigned int
n_nullable	750	unsigned int
cached	1	unsigned int
to_be_dropped	1	unsigned int
fields	0xfeeefeee {col=??? name=??? prefix_len=??? ...}	dict_field_struct *
indexes	{prev=0xfeeefeee next=0xfeeefeee }	dict_index_struct::<unnamed-tag>
search_info	0xfeeefeee {root_guess=??? hash_analysis=??? last_hash_succ=??? ...}	btr_search_struct *
stat_n_diff_key_vals	0xfeeefeee	__int64 *
stat_index_size	4277075694	unsigned long
stat_n_leaf_pages	4277075694	unsigned long
lock	{event=0xfeeefeee wait_ex_event=0xfeeefeee reader_count=4277075694 ...}	rw_lock_struct

setting as verified.  I've reported this bug in the innodb forums also.
http://forums.innodb.com/read.php?3,30,30#msg-30

I forgot to mention you should first run these to setup the file format:

SET GLOBAL innodb_file_format=“Barracuda”;
SET GLOBAL innodb_file_per_table=ON;

Vasil,

can you look at this. Probably easy to fix.

--Heikki

It turns out that standard InnoDB in MySQL 5.1 is also subject to this bug. Fixed there too.

Pushed into 5.1.25-rc

Noted in 5.1.25 changelog.

A potential rare crash in CREATE INDEX for InnoDB tables was fixed.

Setting report to Need Doc Info pending push of fix into 6.0.x.

Setting report to Patch queued pending re-push of this patch.

Pushed into 6.0.6-alpha

The push into 5.1 was reverted, so there is no 5.1.x changelog entry.

The push into 6.0.x was a null merge that changed nothing. Resetting report to Patch Approved pending further push of patch into 6.0.x.

The "parent" report for this set of bugs is Bug#32440.

Merged into 6.0.6-alpha, according to Tim. But the patch has not been pushed into 5.1 yet.

Noted in 6.0.6 changelog.

Setting report to Need Doc Info pending push into 5.1.x.

This fix appears to be present in 5.1.28, but we need confirmation of the correct 3-part version for the changelog so we can document and close.

Thanks!

This was fixed in 5.1.31 (and 6.0.6), not 5.1.28 or 5.1.25.

Noted in 5.1.31 changelog.

Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)