Tips on Reporting VisualGDB Issues

This page provides a few on reporting the issues to Sysprogs support so that we can reproduce the problem on our side easier:

The 3-step Format

The easiest way describe a problem that doesn't involve complex setup is to follow the 3-step format below:

  1. What exactly you are trying to do (e.g. debug an imported STM32 project with OpenOCD after setting a breakpoint in main).
  2. What exactly you do expect to see (e.g. the breakpoint hitting immediately).
  3. Whe exactly do you actually see (e.g. "a frame not in module" message).

Custom Projects

Sometimes the issues only happen for large projects or solutions. Although we usually cannot review a specific project to check why it doesn't build, we still can help you if you follow the troubleshoting steps below:

  1. Create a basic (e.g. "Hello, World" or "LEDBlink" project) with the similar configuration to your project.
  2. Check if the problem can be reproduced. If yes, simply share the setup details with us (e.g. Linux project based on CMake built with a Raspberry Pi cross-toolchain on another Linux machine).
  3. If the problem cannot be reproduced, try to make a list of the differences between the 2 projects and merge them in small batches (doing half at a time will help you pinpoint the cause very fast). E.g. if the debug session freezes, the steps would look like this:
    • Debug a "Hello, World" project with the same configuration.
    • Add the sources from the original project to it.
    • If the problem doesn't reoccur, compare the .vcxproj files of 2 projects and resolve the differences.
    • Compare the .vgdbsettings files of the 2 projects and resolve the differences (e.g. add custom debug steps).

Once you pinpoint a specific difference, let us know. In most of the cases, we are able to add workarounds, options to slightly modify the VisualGDB behavior, or checks for rare cases that will eliminate the problem.

Screenshots

For GUI-related problems please always include a screenshot of the entire window demonstrating the problem. Please do not crop it, as side windows like Solution Explorer often convey important information about your setup, e.g.:

Just one screenshot like this conveys that:

  1. It's a VC++-based project (rules out Advanced CMake, Arduino and Mbed).
  2. Using MSBuild (rules out GNU Make, QMake and basic CMake).
  3. Source structure is loaded (rules out IntelliSense backend communication issues).
  4. Using VisualGDB 5.4 (rules out bugs present in older releases).
  5. Automatic code completion is enabled (changes the order of some internal events).
  6. IntelliSense results are filtered (helps pinpoint inaccuracy issues).
  7. The project is under source control (enables extra checks on the VisualGDB side that may be related).

Diagnostic Logs

VisualGDB provides several ways to make pinpointing problems easier. We recommend checking them before submitting a bugreport and including the relevant parts:

  • View->Other Windows->VisualGDB Diagnostics Console. This window shows detailed logs on all low-level VisualGDB activity. E.g. launched Linux commands, copied files, internal exception traces. If you suspect the problem is related to some external tools, please check this window first.
  • View->Clang IntelliSense Status. This window shows detailed logs from the Clang IntelliSense engine and also the project status as seen by the engine (i.e. the exact list of source files and their flags). It can be helpful in understanding why the IntelliSense cache is being rebuilt too often, why a source file parsing is too slow, or why some IntelliSense suggestions are missing.
  • VisualGDB Project Properties -> Advanced GDB Settings -> Save low-level interaction with GDB. This option will save all lines sent to an received from GDB (with timestamps) int oa log file. It is useful in understanding the inaccurate variable values or stack traces, breakpoints issues and strange GDB crashes.