MySQL Bugs: #61654: Workbench crashs while syncing model

Bug #61654	Workbench crashs while syncing model
Submitted:	27 Jun 2011 11:06	Modified:	12 Jan 2012 17:09
Reporter:	Massimo Cassandro	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S1 (Critical)
Version:	5.2.35	OS:	MacOS (10.7)
Assigned to:		CPU Architecture:	Any
Tags:	workbench

Description:
Trying to syncronize model to server, workbench crashes before display step "Select changes to apply".
I've tried with Linux and Win versions, and always occurs the same error.

These is bug report on OSX:

Process:         MySQLWorkbench [1276]
Path:            /Applications/MySQLWorkbench.app/Contents/MacOS/MySQLWorkbench
Identifier:      com.sun.MySQLWorkbench
Version:         ??? (5.2.34)
Code Type:       X86 (Native)
Parent Process:  launchd [275]

Date/Time:       2011-06-27 13:01:19.115 +0200
OS Version:      Mac OS X 10.6.8 (10K540)
Report Version:  6

Interval Since Last Report:          18412 sec
Crashes Since Last Report:           5
Per-App Interval Since Last Report:  3593 sec
Per-App Crashes Since Last Report:   5
Anonymous UUID:                      1CE69733-B69C-4F9B-B622-605F28624ECB

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000030
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

[continue...]

How to repeat:
Try to sync a model

Complete bug report

Attachment: bug report.txt (text/plain), 53.86 KiB.

What version of server, x.y.z, are you working with? Can you upload any .mwb file that demonstrates the problem?

Server version is 5.0.67

Not repeatable on Windows.

Hello Massimo.
We are not able to reproduce this defect. Can you please give a try with a newer version of MySQL(5.1) and let us know the result?
Thanks.

Hi,
I can't update mysql immediately, I tried to drop the db in a test environment and to rebuild it and this seems to have solved the problem (I don't know what causes the crash, maybe an incorrect fk?)

Unfortunately I can't do the same with the original db at this moment, the best solution would be a sync, but this is what generates the crash. The same problem occurs with all other types of synchronization available.
I made a test with OS X Lion, but with the same results.
Same problems with wb runned on Linux.
Thanks

Thanks for your help so far,
your assumption sounds very likely - but to be able to reproduce and diagnose it we would need the database you experience the problem with. Is it possible for you to create a dump and upload the schema to this report (you can mark uploaded data as private, so only internal developers can see/access it)

Hi,
I've just attached a dump of the structure of the db wich causes crash, with latest versione of my wb file.
In addition of what I wrote last time, I noticed a strange thing on the db I dropped and restored with wb in my test environment: every time I run a sync, there are many alter table commands regardings things I didn't modify. This happens every time. I've copied generated commands in this post
Thank You

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

ALTER TABLE `rubrica`.`famiglia_logos` DROP FOREIGN KEY `fk_famiglia_logos_rubrica_logos_categorie1` ;

ALTER TABLE `rubrica`.`rubrica_liste` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`rubrica_logos` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`rubrica_recapiti_postali` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`rubrica_dati_fiscali` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`rubrica_dati_bancari` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`rubrica_recapiti` CHANGE COLUMN `dataModifica` `dataModifica` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP  ;

ALTER TABLE `rubrica`.`famiglia_logos` CHANGE COLUMN `famiglia_logos_nome` `famiglia_logos_nome` VARCHAR(45) NULL DEFAULT NULL COMMENT 'Non vene mostrato negli elenchi, se associato ad una rubrica'  , CHANGE COLUMN `rubrica_logos_categorie_id` `rubrica_logos_categorie_id` INT(10) UNSIGNED NULL DEFAULT NULL  , 
  ADD CONSTRAINT `fk_famiglia_logos_rubrica_logos_categorie1`
  FOREIGN KEY (`rubrica_logos_categorie_id` )
  REFERENCES `rubrica`.`rubrica_logos_categorie` (`rubrica_logos_categorie_id` )
  ON DELETE SET NULL
  ON UPDATE NO ACTION;

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Please, check if the same problem still happens with a newer version, 5.2.35.

Same issues with 5.2.35

With 5.2.36 on Mac OS X 10.5.x I get only one error during sync with local server 5.0.95:

Executing SQL script in server
ERROR: Error 1253: COLLATION 'latin1_swedish_ci' is not valid for CHARACTER SET 'utf8'

CREATE  TABLE IF NOT EXISTS `thebox`.`agenda2` (
  `agenda_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT ,
...
  PRIMARY KEY (`agenda_id`) ,
  INDEX `dataDA` (`dataDA` ASC) )
ENGINE = MyISAM
AUTO_INCREMENT = 1742
DEFAULT CHARACTER SET = utf8
COLLATE = latin1_swedish_ci
COMMENT = 'agenda theBOX'

SQL script execution finished: statements: 94 succeeded, 1 failed

Please, check if you still get crash with 5.2.36.

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".