MySQL Bugs: #86747: Assertion failed in wbpublic.be.dll

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:	None
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

Description:
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.

Assertion failed!

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

I couldn't repeat on Windows 10 Pro 64-bits. Assign a co-worker to test on Windows 7.

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.

Thanks,
Chiranjeevi.

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!

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.

Someone from MySQL needs to change the "Status" field of this bug report.

Why is the status "can't repeat" when the issue is in fact repeatable?

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

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.

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!

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.

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

STEPS TO REPRODUCE (in my case)

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

NOTES

- The errors shown in log contain "Entity 'auml' not defined" when parsing sql history files - apparently, the umlaut characters are converted to &auml; 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?

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

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

http://bugs.mysql.com/bug.php?id=90591 marked as duplicate of this one.

http://bugs.mysql.com/bug.php?id=91052 marked as duplicate of this one.

Why is Status set to "Can't repeat" even though this defect is in fact a) reproducible; and b) users continue to report it?

Someone please solve this.

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.

Please try version 8.0.12. Thanks.

https://dev.mysql.com/downloads/workbench/

Bug still happens in 8.0.12

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

msft-assert-failed.png

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

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.

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

Bug #92255 marked as duplicate of this one

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.

still happens in 8.0.15. Windows-Server2016

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.

This regularly happens in 8.0.17

It's pathetic this hasn't been fixed!

Please try latest version 8.0.19. Thanks.

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

This is still happening on 8.0.21

Still happening on 8.0.24. It is clearly a bug. How could you now fix it for 3 years?

https://i.imgur.com/TjeuGC1.png