MySQL Bugs: #47460: MySQL service stopped working after trying reverse engineering using workbench

Bug #47460	MySQL service stopped working after trying reverse engineering using workbench
Submitted:	20 Sep 2009 16:01	Modified:	20 Oct 2009 18:33
Reporter:	Ezequiel Santamaria	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.1.34, 5.1.38	OS:	Windows (7 RC 7100)
Assigned to:		CPU Architecture:	Any
Tags:	mysqld, ODBC, reverse engineering, visio, windows, workbench

Description:
MySQL service will stop working after trying to reverse engineer tables using either the ODBC Connector with Visio or via TCP/IP using MySQL Workbench.

How to repeat:
Install ODBC Connector, setup the System DSN, open MS-Visio and select Generic ODBC Driver, then select the MySQL 5.1 Driver and input appropriate credentials.
MySQL Service should stop working.
Using Workbench open workbench, create a new connection and go to Database, Reverse Engineer...
Select any database and  try to reverse engineer. The error should be lost connection to MySQL during Query.

Thank you for the problem report. What exact version of MySQL server, 5.1.x, do you use? Please, send also error log from MySQL server (it is the <hostname>.err file in the data directory usually).

Database version is 5.1.34 but it's not version related since 5.1.38 has the same error.
On top of that, I tried using NAVICAT to dump an SQL file and I obtained the same error, so... so far Visio (using generic ODBC Driver and MySQL Connector), Workbench (via TCP/IP), and Navicat (using Dump SQL file option) they all replicate the same error.
I'm attaching a copy of the log file.

from the .err file

Attachment: errors.txt (text/plain), 2.74 KiB.

Please, send your my.ini file content and the results of:

show create table company\G
show table status like 'company'\G

my .ini file is a default .ini file for a fresh installation of mysql 5.1.38
MySQL version is 64bits version installed on Windows 7 Ultimate 64 bits.
Also, both SQL queries ended in crashing the system
SHOW TABLE STATUS LIKE 'company' and the other one as well

my.ini File

Attachment: my.ini (application/octet-stream, text), 8.71 KiB.

Looks like this your table, company, is corrupted for some reason. Try to run:

check table company extended;

and send the results, if any.

Check also logs at OS level (Event viewer) for unusual messages related to disk or memory.

I can tell that I have been using Win7 RC 64bit Ultimate since it was available for MSDN subscribers with all MySQL 5.0, 5.1, 5.4 and 6.0 servers released in the period. I have not encountered this with numerous clients. 

So whatever happens on your environment is not a general Win7 issue. However "Ezequiel Santamaria" seems to indicate that you are Spanish or Portuguese. So maybe localized file paths in configuration could be an issue (I think I remember a nasty issue with Czech localization of 'Program Files' some years ago).

I have both English and Danish language files installed (use Danish mostly).

A corrupted table 'company' was responsible for crashing MySQL daemon. The only solution found after trying to repair the table unsuccessfully was to delete the table and recreate it using the backed up structure query.

Had you identified possible reasons for this corruption? Was this table created in some older version of MySQL server? Had you found any information about possible hardware failures in the logs?

I have yet to find any errors indicating hardware failure. I'm guessing it could have been more of  logical error rather than hardware related.
I will try to recreate the corruption since I'll be doing repetitive tasks similar to the normal tasks I've been doing while working on that database.
I do feel that a simple table corruption being able to crash the whole server is something to be worried about.

Corruption of InnoDB table is something that happens rarely (and mostly because of hardware failures). That's why it would be nice to know how to repeat it (especially on a different hardware).

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".