MySQL Bugs: #46676: mysqld got exception 0xc0000005

Bug #46676	mysqld got exception 0xc0000005
Submitted:	12 Aug 15:45	Modified:	12 Nov 13:43
Reporter:	Douglas Wright
Status:	Patch approved
Category:	Server: InnoDB Plugin	Severity:	S1 (Critical)
Version:	5.1.37	OS:	Microsoft Windows (Server 2003)
Assigned to:	Calvin Sun	Target Version:	5.1+
Triage:	Triaged: D1 (Critical)

Description:
090812 14:31:00 - mysqld got exception 0xc0000005 ;
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=50331648
read_buffer_size=65536
max_used_connections=29
max_threads=500
threads_connected=19
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1365620 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x1d6964b0
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...
00000001401FBF29    mysqld.exe!get_schema_key_column_usage_record()[sql_show.cc:4739]
00000001401FAEAF    mysqld.exe!get_all_tables()[sql_show.cc:3396]
00000001401FDDBC    mysqld.exe!get_schema_tables_result()[sql_show.cc:6053]
00000001401E8E04    mysqld.exe!JOIN::exec()[sql_select.cc:1730]
00000001401EA50A    mysqld.exe!mysql_select()[sql_select.cc:2390]
00000001401EAA56    mysqld.exe!handle_select()[sql_select.cc:268]
00000001401A29A8    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:5013]
00000001401A4197    mysqld.exe!mysql_execute_command()[sql_parse.cc:2207]
00000001401A99E6    mysqld.exe!mysql_parse()[sql_parse.cc:5936]
00000001401AA71A    mysqld.exe!dispatch_command()[sql_parse.cc:1215]
00000001401AB7E7    mysqld.exe!do_command()[sql_parse.cc:854]
000000014024E677    mysqld.exe!handle_one_connection()[sql_connect.cc:1127]
00000001402C0235    mysqld.exe!pthread_start()[my_winthread.c:85]
00000001403D4057    mysqld.exe!_callthreadstart()[thread.c:295]
00000001403D4125    mysqld.exe!_threadstart()[thread.c:275]
0000000077D6B71A    kernel32.dll!BaseThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 000000001D701700=SELECT COUNT(*) FROM
`information_schema`.`KEY_COLUMN_USAGE`
thd->thread_id=2517
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

How to repeat:
1) Install MySQL 5.1.37
2) Load up PHPMyAdmin, and try to view the information_schema table.
3) Crash

See bug: http://bugs.mysql.com/bug.php?id=32099.

5.1.34 does not have this bug.

PHPMyADMIN

Attachment: phpmyadmin.png (image/png, text), 137.60 KiB.

I couldn't repeat this issue on Vista Premium Home Edition 64-bit.

It must be something to do with the specific database/table structure that I have as it's
reproducible for me on 2 different machines (Server 2003 64-bit, and a 32-bit XP).

I will see if I can narrow it down.

I guess is specific to your database/table so if you are to able to find the cause would
be nice you provide the dump file to create them, also your my.ini file. Thanks in
advance.

if you can upload just the schema for us, it might be enough:
mysqldump --all-databases --no-data --routines -uroot -p > bug46676_schema.sql

if not, then you have to narrow it down with your data.

Minimal schema

Attachment: bug46676_schema.sql (text/x-sql), 5.46 KiB.

I have uploaded the precise schema fragment that causes the crash.

I have also identified that this is a crash-bug specific to the InnoDB plugin (1.0.4).
The version of InnoDB built in 5.1.37 does not crash.

Douglas - are you using the 1.0.4 plugin downloaded from InnoDB website, or the one built
by yourself? Thanks!

The plugin was downloaded.

the stack backtrace doesn't seem to show anything InnoDB plugin related.
Would it reproduce with InnoDB builtin? Would it reproduce when mysqld
is started without InnoDB?

It's 100% reproducible with the plugin installed, and not reproducible at all without it.

So it's definitely plugin-related - whether the problem is on InnoDB's side, or MySQL's
side is something that I can't help with.

Thank you for the report.

Verified as described.

Bug #46745 was marked as duplicate of this one.

Seems like it's related to circular foreign keys with the InnoDB plugin:

SET foreign_key_checks=0;
CREATE TABLE t1 (id int, foreign key (id) references t2(id));
CREATE TABLE t2 (id int, foreign key (id) references t1(id));
SET foreign_key_checks=1;
SELECT COUNT(*) FROM information_schema.key_column_usage;
-- now the server crashes

Scott, in which version, you reproduced the crash with the test case? I could not see a
crash with 5.1.40. Thanks!

This crash is reproducible with InnoDB plugin 1.0.4 + MySQL 5.1.37. But no longer
reproducible after MySQL 5.1.38 (with plugin 1.0.5). Add test case to catch future
regression. Committed into internal repo as r6169.

Yes, my test was 5.1.37.

Is there any other solution to avoid this bug? I also found this bug ,but for some reason
I can't update the version to avoid it. So I want to know how to solve this bug in mysql
5.1.37 & InnoDB 1.0.4.