Here are listed known problems which can arise during development for system other than Android (for Android, look here). There are four groups of problems:

• Problems with underlying tools (GCC, GDB, etc.) which have known workarounds. These are not bugs in WinGDB but rather in the tools. We can't fix them, however there are known workarounds.
• Problems with underlying tools (GCC, GDB, etc.) which not have known workarounds. These are not bugs in WinGDB but rather in the tools. We can't fix them and unfortunately do not know workarounds yet (if they exist at all).
• Problems with WinGDB itself -- bugs and limitations of current version. WinGDB for is still being actively developed. Not all bugs and limitations can be removed immediately. We welcome all feedback and every suggestion is analyzed and usually added to the schedule.
• WinGDB non-bugs -- things that do not work, because they can not for various reasons.

Please be aware of the fact, that WinGDB is a user interface product working with existing tools and can not solve problems inherent to these tools.

Underlying tools problems with known workarounds

GDB sometimes crashes when Autos Window is open.

If you experience a GDB crash, then please check whether standard Autos window is enabled. It doesn't have to be focused or even visible at the moment. The problem is that the Autos window in Visual Studio works by trial-and-error, generating incorrect expressions sometimes, which in turn crash the GDB. This is a bug in GDB, as it should simply report that the expression is incorrect and not crash. Workaround for now is just to disable the Autos window and restart session.

A workaround has been added in the version 1.2. If you still experience that problem, please contact us.

Problems with cross-probing remote build messages.

Visual Studio sometimes stops to open sources after double clicking on remote build message. This is rare condition. In such case restarting Visual Studio should help.

Embedded Linux: some breakpoints do not trigger or some shared libraries are not shown in Modules window.

We have experienced such problems and in all cases it was caused by differences between target and host files in sysroot or debugged application. All the binary files must be identical. Typical sources of that error are:

• Not updated application binary after recompilation.
• Different toolchain versions on the host and the target.
• A library on the target that is missing on the host.

You can use auto-deploy feature available since WinGDB 1.5 to avoid the first problem.

MinGW: Can't debug, "no source available for current location" message shows up. Program is compiled with debug info.

This behaviour has been observed when Cygwin and MinGW were installed on the same machine and Cygwin debugger was used by mistake to debug MinGW-compiled program. Check "Default debugger path" in WinGDB/Preferences and your PATH environment variable.

After breaking running process, the program stops somewhere in some system function with unreadable call stack.

This problem occurs often on embedded Linux systems. It is most likely caused by lack of debugging symbols for system libraries and code optimizations enabled in these libraries. In such cases, GDB cannot correctly determine boundaries of stack frames and displays incorrect stack. WinGDB being a front-end to GDB, can not work around this on its own.

Possible workaronds:

• Use breakpoints: set a breakpoint in some code having debug info, which you know that is called periodically. The program will then stop in well-defined location.

• Use debug versions of system libraries. However this may be not always possible in practice, as few toolchains provide debug versions. Some toolchains offer debug versions of the libraries as a separately licensed add-on (non-free). Consult your toolchain documentation for more information.

• On ARM systems, it may be also related to the problem described here. Use the most recent toolchain version that might contain fixes described in this thread.

Can't attach to a process under Ubuntu 10 or newer.

Ubuntu 10 comes by default with very restrictive security settings which disallow attaching to arbitrary processes (even owned by the same user). That means GDB will be unable to attach, regardless what front-end you are using. You can turn it off by setting the ptrace_scope option to 0 in /etc/sysctl.d/10-ptrace.conf file. You must have root privileges to edit this file. After editing, restart your system. You can find more information here.

Underlying tools problems without known workarounds

GDB (esp. old versions) occasionally crashes.

GDB itself is not perfect and sometimes may crash. We introduced some mechanisms to detect it and display a warning message. However it's still very annoying since it breaks a session. In case you experience such situation, turn on logging in WinGDB preferences. If the crash occurs again, please send it to us along with a bug report. For old GDB versions however, be aware of the fact that fixing such a bug is probably impossible. We do not maintain GDB itself and its maintainers do not patch obsolete versions. Try using other GDB version if possible.

Embedded Linux: the follow fork mode does not work.

This is a problem in some versions of GDB. The GDB docs states that this feature is supported only on HP and GNU/Linux systems (kernel > 2.5.60). On our ARM toolchain (GDB 6.8.50) the "set follow-fork-mode child" command does nothing. The debugger still follows the parent. Unfortunately that means it also won't work in WinGDB.

Debugging with GDB 7.1 is very slow / temporarily freezing.

There is a serious performance bug introduced in GDB 7.1, described here. Please avoid using 7.1 unless the patch mentioned under the link is available to you. If possible, use other version (older or newer). There is no known workaround for this problem. The bug has been fixed in GDB 7.2 and later.

Dynamically loaded libraries are not refreshed correctly when using GDB versions older than 6.6.

The problem occurs if library (so or dll) is loaded with use of dlopen or LoadLibrary. It does not concern libraries linked at build stage.

There is no workaround at the moment. If possible, upgrade your GDB version to at least 6.8.

During build strange error messages appear, but the build succeeds.

When using some toolchains on Windows, you can sometimes see messages like this:

process_begin: CreateProcess(NULL, uname -o, ...) failed.

The build however succeeds. This is an indication of incomplete toolchain which does not provide uname utility, commonly used for platform detection. Makefiles generated by WinGDB use it. In cases we know, lack of this tool does not fail the build. We assume Windows platform in such case. As long as the build is not aborted, this message can be safely ignored.

GDB 7.3.x crashes or steps to incorrect line.

Release series 7.3.x has some new issues, including stepping problems (step over steps to incorrect line sometimes) and crashing when using Python visualizers. None of these problems occurs on 7.2.

One of the symptoms is Debugger stopped responding errors and messages like this in WinGDB session log:

        &"/build/buildd/gdb-7.3/gdb/utils.c:1446: internal-error: virtual memory exhausted:
           can't allocate 1435537552 bytes.\nA problem internal to GDB has been detected,\n
           further debugging may prove unreliable."
    

Strange warning appears in the process console.

The following warning is displayed:

        &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"
    

This warning is completely harmless and does not affect debugging at all. It should go to internal command stream used to communicate between WinGDB and GDB, but instead GDB displays it as if it were process output. This is obviously a bug in GDB, introduced in version 7.0.

WinGDB known bugs and limitations

A problem with loading the Add-In under Windows Vista or Windows 7 with UAC enabled and Visual Studio not being run as an Administrator.

Install recent version of WinGDB (2.2 or later). Older versions used to require that VS had to be run as an Administrator, but newer version don't do it anymore. On the other hand, if your version is 2.2 or later, then it is a bug and contacting our support (support@wingdb.com) is recommended.

Remote process console has some refreshing problems.

Sometimes the console is painted incorrectly. Also it does not yet support full set of VT100 commands, therefore it doesn't pass the vttest suite.

Some problems with console refreshing observed on Windows XP turned out to be related to font display problem with particular font used in the console. This occurs for unclear reasons and restarting Windows makes the problem disappear.

Remote process console does not echo user input.

In Unix terminals, echoing the input is optional. Some clients need it, while for some it would be undesirable (e.g. curses programs). Currently WinGDB does not support local echo mode. The input is correctly served and passed to debugged process, although is not visible in process console window. It will change in some future release.

Visualizers currently work only on remote sessions, not MinGW/Cygwin/Embedded.

This problem will be addressed on WinGDB side in future version. However, to use Visualizers you must have a Python-enabled GDB, and unfortunately most of currently available GDB versions for Windows does not support Python yet.

WinGDB non-bugs

webOS support has not been updated for a long time.

Unfortunately webOS is not supported anymore by its vendor and the future of the system is currently unclear. We also do not have any registered customer who develops applications for webOS. Possibly (if commercially feasible) we will resume webOS support and update it to recent version of the system.