The following is a list of tips and information that is helpful for reporting a MySQL Workbench bug.
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
The MySQL Workbench Log file
The log file location can be found using , 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.
Visit http://bugs.mysql.com/ and use one of the "MySQL Workbench" bug categories.
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.
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 OS X and
Linux, and -log-level on Microsoft Windows
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 6.3.5\"shell>MySQLWorkbench.exe -log-level=debug3# OS X shell>cd /Applicationsshell>MySQLWorkbench --log-level=debug3# Linux (Ubuntu) shell>cd /usr/binshell>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.
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).
OS X
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:
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.