Appendix D How To Report Bugs or Problems

The following is a list of tips and information that is helpful for reporting a MySQL Workbench bug.

A useful bug report includes:

The exact steps taken to repeat the bug, ideally as a video if the bug is tricky to repeat.
A screenshot, if the bug is visual.
The error messages, which includes text sent to stdout and the GUI.
A copy of the MySQL Workbench Log file.
The log file location can be found using Help, Locate Log Files from within MySQL Workbench.

Bugs that cannot be reproduced are difficult and nearly impossible to fix, so it is important to provide the steps necessary to reproduce the bug.

Where to report a bug

Visit http://bugs.mysql.com/ and use one of the MySQL Workbench bug categories.

Log Levels

There are six different log levels, with increasing levels of verbosity: error, warning, info, debug1, debug2, and debug3. By default, the error, warning and info levels are enabled. There is also a "none" level that disables logging.

Important

Please enable the debug3 level before generating a log for the report.

The enabled error log levels can be configured using an environment variable, or by using a command line parameter.

Both the environment variable and command line variants accept a single error level, but enabling a more verbose option will implicitly enable the levels below it. For example, passing in "info" will also enable the "error" and "warning" levels.

Environment variable: WB_LOG_LEVEL
Command line option: --log-level on macOS and Linux, and -log-level on Microsoft Windows

Note

If both the command line and environment variable are set, the command line takes precedence.

For example:

# Microsoft Windows
shell> cd "C:\Program Files (x86)\MySQL\MySQL Workbench CE 8.0.23\"
shell> MySQLWorkbench.exe -log-level=debug3

# macOS
shell> cd /Applications
shell> MySQLWorkbench --log-level=debug3

# Linux (Ubuntu)
shell> cd /usr/bin
shell> mysqlworkbench --log-level=debug3

If the info level is enabled, the system information and all paths used in the application are also logged. On Microsoft Windows, this also means that the log file contains the full set of current environment variables that are active for the program.

Operating System Specific Notes

Microsoft Windows

Log file location: Near the user's app data folder, such as C:\Users\[user]\AppData\Roaming\MySQL\Workbench\log for Microsoft Windows 7.
In case of errors (or exceptions), the log file contains the stack trace to the point MySQL Workbench can track it (usually only C# code, and not C++ code). Also, all warnings are added to the log if the warning (or greater) log level is enabled.
If it is a crash and that cannot be replicated by the MySQL Workbench team, and the stack trace cannot be obtained, we will request a crashdump. Instructions for enabling a crashdump can be found here, and please also read the MSDN details for this as we need a full dump, and not the mini dump.
For crashes related to display issues, start MySQL Workbench with the -swrendering parameter (and only then, as it switches off OpenGL rendering, which is of no use in WBA or WQE). This output will be added to the log file.
If it is a crash when MySQL Workbench is started (especially if the error report includes something about kernelbase.dll), we will ask you to run depends.exe on the MySQLWorkbench.exe binary, and ask for the reported errors.
If it is a crash when MySQL Workbench is started, and it is a 64-bit version of Microsoft Windows, check that the correct MSVC runtimes are installed. Often people install the 64-bit version of them, but only the 32-bit will function. More precisely: MSVC 2010 runtime x86 (32-bit).

macOS

Log File Location: ~/Library/Application Support/MySQL/Workbench/logs
System crash logs generated for Workbench are in ~/Library/Logs/DiagnosticReports/MySQLWorkbench*

Linux

Log File Location: ~/.mysql/workbench/logs
For a crash, we might ask for a stack trace that can generated by gdb by using the following steps:
Note
Because published MySQL Workbench builds lack debug symbols, this step is optional and will probably not be necessary.
- In shell, execute source /usr/bin/mysql-workbench
- Quit MySQL Workbench
- In shell, execute gdb /usr/bin/mysql-workbench-bin
- In the gdb interface, type run
- In MySQL Workbench, repeat the crash
- In the gdb interface, type bt
If it is a crash, also run glxinfo. If that also crashes, then it is a driver/X server problem related to OpenGL that is not specific to MySQL Workbench.