Here are listed known problems which can arise during development. There are four groups of problems:
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.
This is due to compatibility-breaking change in this version of Visual Studio. This can be solved by setting an option in Visual Studio settings, as described in this section of the manual.
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.
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.
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:
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.
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:
Ubuntu 10 (and recently Fedora 22) 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. This is indicated by warnings similar to this one:
ptrace: Operation not permitted.
You can turn it off by setting the ptrace_scope option to 0 in /etc/sysctl.d/10-ptrace.conf file under Ubuntu. You must have root privileges to edit this file. After editing, restart your system. You can find more information here.
Under Fedora, at least in version 22, there is no config file by default. You can create one, issuing the following command as root:
echo kernel.yama.ptrace_scope=0 > /etc/sysctl.d/98-yama.conf
After editing, restart your system. You can find more information here.
There is a packet size problem. WinGDB has a workaround for it. Go to WinGDB/Preferences/Network page and enable Limit SCP upload packet size option.
Remote machine may be configured to shutdown the connection after some time of inactivity. If you experience this, you may try using TCP keep-alive option as a workaround. Go to WinGDB/Preferences/Network page and set TCP keep-alive period value to some large number of miliseconds. For example, 60000 means that every minute a special packet will be sent to prevent the inactivity timeout.
'Stop in main()' feature is actually redundant and deprecated. A much better alternative is to create a function breakpoint in Visual Studio. You can put it on any function.
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.
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.
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.
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.
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.
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."
These crashes seem to be fixed in GDB 7.4. Also the stepping problem does not occur in GDB 7.5 (although it is still present in 7.4.x). Use at least 7.5 version if you experience any of these issues.
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.
While not a problem with underlying debugger, these issues might be an outcome of wrongly set Windows permissions. This can happen especially when you run Visual Studio both in Administrator mode and without it. Files created in Administrator mode may differ in permissions from the ones created in user mode, and might not be accessible from the user mode. WinGDB has no control over that, as it depends on your system configuration.
If you experience issues mentioned in the title (e.g. your last settings from process launch are not saved), please find WinGDB directory inside ProgramData directory on your hard drive and review all file permissions. If current user account is not present on the permission lists with Full control rights, add the account. Another solution is to delete those files. WinGDB will recreate them, but you will lose your settings this way.
Also avoid mixing running Visual Studio as Administrator and normally, as the above problems may appear again. Old versions of WinGDB required VS to be run as Administrator, but since WinGDB 2.2 this is not needed any longer and not recommended.
WinGDB remembers its state during Visual Studio runs. However, under Visual Studio 2010 the toolbar disappears without any reason (sometimes you can even see it "blinking" for a brief moment). We did not encounter such behavior in any other Visual Studio version, therefore it is considered as a bug in Visual Studio 2010. Generally it is recommended to avoid Visual Studio 2010 due to numerous bugs and slowness. Use a newer (or older) version if possible.
A temporary workaround is to reenable WinGDB toolbar in the Customize dialog.
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.
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.
In Unix terminals, echoing the input is optional. Some clients need it, while for some it would be undesirable (e.g. curses programs). WinGDB supports optional local echo mode. When it is not active, the input is correctly served and passed to debugged process, although is not visible in process console window. When local echo is activated, the input is additionally echoed into the window. You can enable local echo mode by clicking a button on the toolbar above the process console window.
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.
It has been reported that customizations added to WinGDB toolbar are not remembered after closing Visual Studio. This is a minor bug which will be addressed in some future release. Note that this issue is completely different than the problem with disappearing toolbar under VS 2010. These two are unrelated. THe customization problem does not depend on particular VS version.
A temporary workaround is just avoid using toolbar customization - it is not considered a critical WinGDB feature. You can access all WinGDB functions from menus.
Sometimes we got reports about installation problems. Those are rare (just a couple of reports each year) but inevitable due to Windows systems' complexity and amount of circumstances and settings that can break compatibility. An example are various Group Policy settings, which in extreme cases can block software installation or functioning entirely. Please do not alter Group Policy or other Windows security settings unless you really know what you are doing.
Other causes may include misbehaving third party software, incorrectly configured antivirus, and in very rare cases -- hardware problems. Especially faulty SSD drives can cause all sorts of weird behavior, as they give errors in access to particular files.
If you encounter problems during installation of WinGDB, please first ensure that you are using the latest version available from our website. Then perform the following diagnostic procedure:
msiexec /i WinGDB-latest_trial.msi /lvx* wingdb.log
Doing so will allow us to find a solution to the issue. Bear in mind that we do not have access to your system and no idea what are values of various settings, third party software and possible other properties of your system which can affect operation. Please attach the msiexec log and every information you might think to be relevant. This will help to find the solution quickly.
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.
In general, messing with system clock can lead to various unpredictable results. Do not do this. If you need more time for evaluation, just write us and we'll make extended eval key for you. Also, if you find WinGDB useful, please consider purchasing it. We are an independent software vendor from Central Europe. By purchasing a license, you support further development of WinGDB, IntegraStudio, VSScript and perhaps other quality tools in the future.