MySQL Bugs: #71203: MySQL Workbench crashes every time I synchronize

Bug #71203	MySQL Workbench crashes every time I synchronize
Submitted:	21 Dec 2013 21:24	Modified:	7 Feb 2014 8:37
Reporter:	Bill Antalek	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	6.0.8	OS:	MacOS (10.8)
Assigned to:		CPU Architecture:	Any
Tags:	crash, synchronize

Description:
Whenever I synchronize my model to the database, the application crashes. It does seem to go to the end where you click the finish button, but then it crashes. In fact, any time I close the synch dialog box it crashes, even on the steps preceeding the end. It does seem to update the database.

How to repeat:
Open the Synchronize Database dialog box and close it. Repeats 99% of the time.

Thank you for the bug report. Could you please provide you model file? I could not repeat on Maverick OS. Thanks.

Same thing here. I am attaching my model file. 

I am on OS X 10.8.5

simple model file used for exercising this bug

Attachment: test_model.mwb (application/octet-stream, text), 7.10 KiB.

I have made a change to test_model - added 'child_attribute' column to child.  I am now going to synchronize the model

This is the SQL generate as I synch test_model - seems OK:

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,ALLOW_INVALID_DATES';

ALTER TABLE `mydb`.`child` 
ADD COLUMN `child_attribute` VARCHAR(45) NULL DEFAULT NULL AFTER `parent_id`;

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

problem report file - crash after synch of test_model

Attachment: test_model_synch_problem_report.txt (text/plain), 61.87 KiB.

I am running OS X version 10.8.5

Crashing after synchronizing the model happens 100% of the time for me so far.

Synch appears to complete OK

Fixed as of the upcoming MySQL Workbench 6.1.2 release, and here's the changelog entry:

On Mac OS X, executing "Synchronize Database" could crash MySQL Workbench.

Thank you for the bug report.

This is NOT fixed.

I'm still having this issue running Mac OSX 10.8.5, system info

MySQL Workbench Community (GPL) for Mac OS X version 6.1.4  revision 11773 build 1454
Configuration Directory: /Users/derek/Library/Application Support/MySQL/Workbench
Data Directory: /Applications/MySQLWorkbench.app/Contents/Resources
Cairo Version: 1.10.2
OS: OS X 10.8.x Mountain Lion
CPU: 4x Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz - 16.00GiB RAM
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b12)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

This bug should be reopened. I am experiencing this issue on every attempt to synchronize while pressing the Close button after the sync happens. The main issue being caused here is the SQL is executing. The prompt after to close the synchronization window causes mysql workbench to close, which is causing the model to not be saved before the close. I can start saving my model BEFORE synchronizing but it seems like a dependency that could turn out to be a headache.

System Specs : 
 Macbook Pro - Early 2015
 Processor 2.7GHz Intel Core I5
 Memory : 16GB 1867 MHz DDR3
 Graphics : Intel Iris Graphics 6100 1536 MB

Workbench Details : 
 Version : 6.3.3.0
 Build     : 592
 Bit         : 64

I downloaded version 6.3.7 build 1199 CE (64bit) and that corrected the issue.

In version 6.3.9 it's still an issue. Workbench crashes everytime I try to sync the model with the DB schema.

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

Could this please be fixed? It is quite frustrating and has been happening in nearly every version of MySQL Workbench. For me the process goes: Reverse Engineer DB -> Synchronize with Any Model -> Crashes after selecting the source/target database and trying to download the schema data. I can make it happen almost every single time. About 10-20% of the time it doesn't crash.

Still happening on the latest version, would a crash dump help?