Forum Replies Created
-
AuthorPosts
-
support
KeymasterThanks, we have found the root cause. It looks like your system has multiple network interfaces marked with the (WSL) tag, so VisualGDB cannot determine the one to use for WSL connections.
We have fixed the issue that was preventing VisualGDB from showing a more descriptive error message in this build: VisualGDB-5.6.5.4337.msi
VisualGDB will now list all the interfaces it found in the error message, so you can manually select the one you would like to use for WSL targets via Tools->Options->VisualGDB->General->Other->Linux Subsystem Network Interface.
support
KeymasterHi,
It looks like your antivirus is interfering with vgagent. Please see this page for more details.
support
KeymasterHi,
Please try updating to the latest VisualGDB 5.6 Beta 5 and deleting the .visualgdb subdirectory in the project folder. If the problem persists, please share the updated stack trace, and we will investigate this further.
support
KeymasterHi,
There is no special command to regenerate a Makefile. It is a part of the project, and deleting it is similar to deleting any other project file. Our best advice would be to create a new similar project from scratch, and try to copy the accidentally deleted files from it, although they may need some adjustment.
September 3, 2021 at 21:49 in reply to: Visual Studio Freezes when selecting a Unit Test with Simulation Platform #31258support
KeymasterThanks, we have reproduced the problem on our side. Turns out, the latest Visual Studio 2019 freezes when trying to select a test without a source location (this only affects the simulation platform, as VisualGDB does not support parsing of the DWARF symbols in Win32 EXEs).
We have updated VisualGDB to report a dummy location for these tests. Please try this build: VisualGDB-5.6.5.4323.msi
support
KeymasterHi,
It looks like you have specified the commands incorrectly. Please try updating them as shown below:
Command: make
Arguments: checkSeptember 2, 2021 at 08:24 in reply to: Visual Studio Freezes when selecting a Unit Test with Simulation Platform #31250support
KeymasterHi,
Please try attaching another Visual Studio instance to the frozen one and obtaining the call stack as shown on this page. Please attach the call stack here and we will investigate it further.
support
KeymasterHi,
Most likely, you are building the deprecated HLA_Multicore platform. Please try switching it to Mainstream via the VS platform selector.
We have also just updated the repository, removing the HLA_Multicore platform completely.
support
KeymasterHi,
According to our records, your support period has expired. Please kindly renew it here and we will help you get everything working.
support
KeymasterHi,
This is an Arduino-based project and not an ESP-IDF-based one. Arduino projects use the Arduino build system that can be considerably slower than CMake+Ninja.
Either way, you can try building the project outside VisualGDB as shown here: https://visualgdb.com/documentation/projects/arduino/#troubleshooting
support
KeymasterThanks for renewing your license. The slow build might come from the GNU Make tool used by the ESP32 projects. Please make sure your project uses CMake and Ninja, and not the legacy GNU Make. You can recheck it via VisualGDB Project Properties -> CMake Build Settings.
If this doesn’t help, please try exporting the configuration and build command lines from VisualGDB to batch files as shown here. Does running them manually also result in a slow build?
support
KeymasterHi,
This looks like a message coming from the ESP32 OpenOCD port that is maintained by Espressif. Most likely, some changes to the project configuration are either incompatible with JTAG debugging, or trigger a bug in OpenOCD.
Our best advice would be to try erasing the FLASH memory via esptool.py and reverting the change that triggered it. If you need further help with this, please consider submitting a bug to the ESP32 OpenOCD repository on Github.
support
KeymasterHi,
Good to know you know what is going on. In general, it is hard to suggest anything specific for a complex project that was created by someone else and involves numerous external points of failure.
If you believe VisualGDB is not working as expected, please try reproducing the problem completely from scratch (i.e. from creating a new project) and sharing the repro steps per our problem reporting guidelines. If we are able to reproduce the issue on our side, and can confirm that it is caused by VisualGDB, we should be able to resolve it.
support
KeymasterSorry, unless we can reproduce the issue on our side, we will not be able to address it. We will keep an eye out for other users reporting similar behavior and will fix it as soon as we are able to reproduce it.
-
AuthorPosts