Bug #20366 reverse engineering bug
Submitted: 9 Jun 2006 19:46 Modified: 14 Jun 2006 17:53
Reporter: Sheeri Cabral (Candidate Quality Contributor) Email Updates:
Status: Won't fix Impact on me:
None 
Category:MySQL Workbench Preview Severity:S3 (Non-critical)
Version:1.0.6 beta OS:Windows (Windows XP Pro)
Assigned to: CPU Architecture:Any

[9 Jun 2006 19:46] Sheeri Cabral
Description:
When attempting to reverse engineer a (remote) database, the workbench crashed.

I connected, selected the schema, clicked "Next" on the "Schema Selection" window, and then it popped up an alert box with the title of "Error" and the body:

** ERROR ** file c:\dokumente und einstellungen\mike\eigene
dateien\work\mysql-gui-common\library_grt_modules\source\myx_get_mysql_reveng.c: line 1316: assertion failed: (!src[i] && !dst[1]) aborting…

and then when I click "OK" I get another alert box

---------------------
(Title of the box:  Microsoft Visual C++ Runtime Library)

message: Runtime Error!

Program:  C:\Program Files\MySQL\MySQL Workbench\MySQLWorkbench.exe

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information

---------------------

When I click OK the workbench closes (crashed).

How to repeat:
I was able to repeat on different architectures:
Windows (XP Pro) localhost running MySQL 5.0.19-nt
Fedora Core 3 i386 remote running MySQL 5.0.19-standard-log
Solaris 5.9 sparc remote running MySQL 4.0.20-log (I had to take out the DEFAULT CHARSET=utf8 in the table definitions for it to work on that version of MySQL).

I reduced the problem to the following schema -- workbench gives the above errors when you run the following commands, and then try to reverse engineer the "cannotREme" database:

drop database if exists cannotREme;
drop database if exists testdb;
create database testdb;

use testdb;
CREATE TABLE `forRefDB` (
  `siteId` int(10) unsigned NOT NULL,
  `uid` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`uid`,`siteId`)
) ENGINE=InnoDB ;

create database cannotREme;
use cannotREme;
CREATE TABLE `forRefTable` (
  `id` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB ;
  
CREATE TABLE `mainTable` (
  `uid` int(10) unsigned NOT NULL,
  `siteId` int(10) unsigned NOT NULL,
  `refId` int(10) unsigned NOT NULL,
  KEY `refId` (`refId`),
  KEY `siteId` (`siteId`),
  KEY `uid` (`uid`,`siteId`),
  CONSTRAINT `mainTable_ibfk_1` FOREIGN KEY (`refId`) REFERENCES `forRefTable` (`id`),
  CONSTRAINT `mainTable_ibfk_2` FOREIGN KEY (`uid`, `siteId`) REFERENCES `testdb`.`forRefDB` (`uid`, `siteId`)
) ENGINE=InnoDB ;

Suggested fix:
no clue.  However, I will note that changing anything eliminates the reverse engineering error.

Removing either one of the constraints in "mainTable" results in reverse engineering working fine.  (Therefore you cannot remove any of the keys or fields on that table.)  Removing either "uid" or "siteId" from the 2nd foreign key of "mainTable" also does not produce an error when reverse engineering is attempted.

Adding a PRIMARY KEY to "mainTable" (I tried with "uid") does not make the error go away.

When I put "forRefDB" into the "cannotREme" database, reverse engineering works fine.

I'll also note that the following work fine when reverse engineering other databases:  foreign keys, foreign keys referencing other databases, two foreign keys in one table, two foreign keys in one table where one refers to a table in another database, keys, primary keys, etc.  It really seems to be this particular combination that breaks.
[14 Jun 2006 17:53] Tonci Grgin
Hi Sheeri and thanks for your bug report.
Verified as described by reporter on
  MySQL 5.0.23-debug BK on Suse 10
  MySQL Workbench 1.0.6 beta
  WinXP Pro SP2
with script provided.