Bug #86747 Assertion failed in wbpublic.be.dll
Submitted: 19 Jun 2017 15:34 Modified: 4 Apr 2020 23:50
Reporter: J Scavok Email Updates:
Status: No Feedback Impact on me:
Category:MySQL Workbench Severity:S3 (Non-critical)
Version: 6.3.9 CE build 10690321 (64 bit) OS:Windows (Windows 7 Professional Service Pack 1)
Assigned to: MySQL Verification Team CPU Architecture:Any
Tags: assertion, microsoft visual c++ runtime library

[19 Jun 2017 15:34] J Scavok
Running a query under certain conditions causes an assertion failure in wbpublic.be.dll

How to repeat:
1. Turn-on or restart your PC

2. Start Workbench 6.3.9

3. Connect to database (Control U)

4. Execute a query such as

select table_schema, table_name from information_schema.tables where engine = 'innodb';

Note: do NOT execute a `use` statement.

5. An assertion failure occurs in wbpublic.be.dll

6. Quitting Workbench, restarting it, and doing steps three and four (with this particular statement, since it does not require a `use` statement) now works as it should, i.e., there is no assertion failure.
[19 Jun 2017 15:35] J Scavok
Assertion failed!

Attachment: pos-workbench-assertion-failed.jpg (image/jpeg, text), 39.97 KiB.

[19 Jun 2017 20:12] MySQL Verification Team
I couldn't repeat on Windows 10 Pro 64-bits. Assign a co-worker to test on Windows 7.
[20 Jun 2017 9:32] Chiranjeevi Battula
Hello Scavok,

Thank you for the bug report.
I could not repeat the issue at our end using with Windows7 64 bit and MySQL workbench 6.3.9 version.
If you can provide more information, feel free to add it to this bug and change the status back to 'Open'.

Thank you for your interest in MySQL.

[21 Jun 2017 2:15] J Scavok
Thanks for checking, guys. 

If you can do so, make Workbench already have an EER diagram open. (That is: when Workbench starts, it automatically loads the last .mwb file it had open.) In my case, my EER diagram has 22 tables in it.

As long as an EER diagram is open, this is 100% reproducible for me!
[30 Jul 2017 18:16] Brian Smither
This happened to me. First run after having the MSI upgrade from 6.3.7.

Win7 x64

Right-clicked on a table name, clicked on Select Rows - Limit 1000, window pops up. Click Abort and the workbench exits.

Restart, repeat, no popup.
[30 Jul 2017 19:21] J Scavok
Someone from MySQL needs to change the "Status" field of this bug report.
[2 Aug 2017 20:18] J Scavok
Why is the status "can't repeat" when the issue is in fact repeatable?
[2 Oct 2017 6:09] Konstantin Kalinin
Hello! I have the same issue with the same steps to reproduce.
Guys from MySQL, I think you should request more details and reproduse it. This is realy annoyed bug. 
Thank you
[3 Oct 2017 13:01] John Black
I am having the same problem.  The steps in the original test case reproduce the bug for me.

One additional observation: when I see the C++ exception, I generally abort the MySQL Workbench process and start it again.  When restarted, Workbench seems to work fine.  However, if I leave it running unused for a few hours (e.g., overnight) then come back and run any query the Workbench process will throw the same C++ exception and have to be restarted, at which point it runs OK again.
[3 Oct 2017 19:06] J Scavok
Despite multiple reports that it is an issue, the MySQL team chooses to ignore us.

I've given up reporting new defects with Workbench because these people can't be bothered to fix critical issues in a timely manner.

And no published release schedule!

And things that used to work in prior versions, are now broken, so clearly these amateurs lack regression testing.

In short: Workbench has become crapware!
[13 Oct 2017 15:45] John Black
I looked at the log files (Help -> Locate Log Files) and noticed that there were parsing errors coming from queries that I had not run for a log time.  Further investigation showed these queries were contained in the sql_history files.  Apparently these files are parsed at startup.  On my PC these are in C:\Users\mylogin\AppData\Roaming\MySQL\Workbench\sql_history.  I deleted the files under sql_history and restarted MySQL.  The "Assertion failed..." problem has not recurred.
[23 Oct 2017 3:46] J Scavok
@John Black;

I for one THANK YOU for your diligence in discovering how to get rid of this annoyance!

Aside: it's a sad reflection on at least one Crapbench employee who couldn't be bothered to trace this error message in the source code back to its source and discover its root cause.
[26 Oct 2017 8:07] Kari Aliranta

1. Add a table with "DEFAULT CHARSET=utf8" and "COLLATE=utf8_swedish_ci" defitions, and a field with "varchar(255) COLLATE utf8_swedish_ci NOT NULL" defitions (haven't tested with other defitions, but this is what I have)

2. In Mysql workbench, insert data with umlaut characters to field defined above (in my case, the data inserted to the field is "Kajaani pääasema")

3. Restart the PC (bringing it out of long sleep seems to be enough, too)

4. Observe the error


- The errors shown in log contain "Entity 'auml' not defined" when parsing sql history files - apparently, the umlaut characters are converted to ä in the file, and the parser can't handle them (I attached a private log file for this)

@John Black: do you have similar parse errors in your logs?
[26 Oct 2017 12:06] John Black
@Kari Aliranta

Regrettably I did not save the log files.  However, the parse errors that I saw definitely were complaining about "illegal characters" in the logs.
[31 Oct 2017 8:36] Kari Aliranta
Also, I can confirm that deleting the sql_history files with problematic content helps and stops the crashes. 

(I didn't find a way to stop the history logging, so the problem might recur once I run the problematic queries again.)
[24 Apr 2018 10:02] Chiranjeevi Battula
http://bugs.mysql.com/bug.php?id=90591 marked as duplicate of this one.
[29 May 2018 7:27] Chiranjeevi Battula
http://bugs.mysql.com/bug.php?id=91052 marked as duplicate of this one.
[29 May 2018 15:09] J Scavok
Why is Status set to "Can't repeat" even though this defect is in fact a) reproducible; and b) users continue to report it?
[26 Jun 2018 12:27] Vivek Sarma Ravuri
Someone please solve this.
[26 Jun 2018 14:24] John Black
I can easily reproduce this bug on Windows 7 by simply running queries from Workbench then leaving Workbench open on my desktop overnight.  When I come in the next day, the first attempt to run any query fails every time.  Aborting and restarting Workbench solves the problem.

Maybe sessions that have been idle for a long time are getting disconnected by something in Windows 7, in which case maybe there's some Windows setting (policy, firewall, etc.) that would help.  I can say with certainty that we do not see the same behavior with Linux clients.
[28 Jul 2018 3:53] MySQL Verification Team
Please try version 8.0.12. Thanks.

[30 Jul 2018 6:04] Maor Shiffman
Bug still happens in 8.0.12
[31 Jul 2018 5:54] Maor Shiffman
More information:

Microsoft Visual C++ Runtime Library
Assertion failed!

Program: ...Files\MySQL\MySQL Workbench 8.0 CE\wbpublic.be.dll
File: G:\ade\build\sb_0-29457156-15306205.../forced_...urn.hpp
Line: 47

Expression: false

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)
Abort   Retry   Ignore   
[31 Jul 2018 19:50] John Black

Attachment: mysql_crash.png (image/png, text), 16.16 KiB.

[31 Jul 2018 19:53] John Black
The problem still occurs for me in 8.0.12.  See previously attached (by me) image.

Besides occurring at startup, it also occurred recently about 10 minutes after running a successful query, with no user interaction between the query and the assertion failure.
[29 Aug 2018 1:00] Bugs System
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".
[4 Sep 2018 10:58] MySQL Verification Team
Bug #92255 marked as duplicate of this one
[8 Mar 2019 1:47] Ria L
Happened on me. Win 10 Pro 64 bit. MySQL version 8.0.13 build 13780177 CE (64 bit).
Assertion failed on first query execution (after restart). It does not happen again when I re-open the MySQL Workbench.
[3 Apr 2019 8:42] David Lopez
still happens in 8.0.15. Windows-Server2016
[10 Dec 2019 5:12] songtao lou
I use Win7, many years for this OS, I cannot remember when the problem first occur.
At first stage, I tried to reinstall using newest version, but not useful, but at least I can endure. It occurs occassionally, and restart workbench everything works fine. However recently, I cannot use it entirely. No matter restart how many times, the error popup when I do first query.
[4 Mar 2020 21:56] J Scavok
This regularly happens in 8.0.17

It's pathetic this hasn't been fixed!
[4 Mar 2020 23:50] MySQL Verification Team
Please try latest version 8.0.19. Thanks.
[5 Apr 2020 1:00] Bugs System
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".
[13 May 2020 10:50] Gary McMeekin
I still get this error on 8.0.19. The issue occurs when changing the Output panel to History after the program has been open for a while. Strangley it doesn't happen when you immediately change to history on first start.
[27 Sep 2020 15:48] S D
This is still happening on 8.0.21
[9 May 2021 20:06] Emre Atila
Still happening on 8.0.24. It is clearly a bug. How could you now fix it for 3 years?