MySQL Bugs: #71177: Intermittant crash upon executing query

Bug #71177	Intermittant crash upon executing query
Submitted:	18 Dec 2013 20:43	Modified:	15 May 2014 23:14
Reporter:	Alan Schmidt (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S3 (Non-critical)
Version:	mysql-workbench-community-6.0.8-1.fc19.	OS:	Linux
Assigned to:		CPU Architecture:	Any

Description:
When executing a query, workbench will seize up and disappear.

Upon re-launch, the query will have been auto-saved. Immediately executing the query typically succeeds.

How to repeat:
There doesn't seem to be much pattern to it, except it SEEMS to happen LESS if I first expand the schema in the schemas sidebar.

It also SEEMS to happen MORE upon switching from one schema to another.

However, switching schemas does not automatically trigger the error, and expanding the schema in the sidebar does not automatically prevent a crash.

core_backtrace as provided by abrt

Attachment: core_backtrace (application/octet-stream, text), 27.05 KiB.

var_log_messages as provided by abrt

Attachment: var_log_messages (application/octet-stream, text), 12.34 KiB.

I have a coredump if it will help. However, it is 119M, and too large for the "Files" tool.

what version of fedora do you use?

I've been reporting this against the mysql-workbench packaged with Fedora through versions 18 and 19.

Now I'm on 20, and I figured I'd try the version supplied directly from Oracle.

So... The answer is 20, but this particular problem has been around for a while, but may not have reached your ears.

A backtrace I tried to do today

Attachment: backtrace (application/octet-stream, text), 62.19 KiB.

I'm not sure I have all the right symbols to do this backtrace correctly.

The message in Thread 1 seems reminiscent of the problem where if you change schemas and DON'T expand the tree in the sidebar, you're much more likely to trigger the error:

"unhandled exception (type std::exception) in signal handler:
what: Attempt to dereference NULL TreeNode"

maps from my backtrace

Attachment: maps (application/octet-stream, text), 97.58 KiB.

Try renaming the ~/.mysql/workbench/cache directory to something else. If that solves it, please attach the files here.

I don't seem to have a ~/.mysql/workbench/cache directory.

Inside ~/.mysql/workbench, I only have

connections.xml
libraries/
log/
modules/
other_connections.xml
scripts/
server_instances.xml
shell_bookmarks.txt
shell_history.txt
snippets/
sql_history/
sql_workspaces/
starters_settings.xml
user_starters.xml
wb_options.xml
wb_state.xml

Please give a try to the 6.1.1 package for fedora 20 if you have a chance.

So far so good. :-D

I'll use it exclusively this week and next, and I'll let you know if the problem comes back.

Shucks.

Nope, it still does it.

I can try another retrace if you think it will help....?

We've fixed something that might be this bug in 6.1.2, so please try it when it's out.

Please try version 6.1.2 and report back whether it's better. A race condition similar to this one has been fixed in it.

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

I've been using 6.1.2 for almost a week now, and it's looking GREAT! No crashes so far.

Thanks!

Closing as reporter claims it no longer crashes