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

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 OS X and
Linux, and -log-level on Microsoft Windows

Note

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

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

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:

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.