[support]

Hi,

The second IntelliSense popup looks like it’s coming from another VS extension. Most likely, it does not recognize VisualGDB, and tries to show its popup nonetheless. You can try disabling other VS extensions to see which one it is.

Another option would be to change the mechanism used by VisualGDB to display the suggestion popups (Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI). Some of the options there could interfere less with the other extension.

[support]

Hi,

Please make sure you can get it working outside VisualGDB first. Once it is working, feel free to share the details about your setup, and we will point you to the relevant VisualGDB documentation.

[support]

No problem. This could be a bug that gets occasionally triggered under some conditions, although we would need more information to pinpoint it. Normally, the window should look like this on the dark theme:

We have slightly simplified the theme loading logic in VisualGDB and added extra logging to it. Please try this build: VisualGDB-6.0.103.5201.msi

If the problem persists, please follow the steps below:

1. Start a debug session.
2. Open and enable View->Other Windows->VisualGDB Diagnostics Console.
3. Open a memory window that was not open before (e.g. Memory 2). You can also try closing and reopening it.
4. Check the diagnostic log for messages mentioning Memory editor.

If you could post the exact messages you get along with the exact action that triggers them (e.g. opening a memory window for the first time), we should be able to narrow it down.

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks, this looks like the device type auto-detection wasn’t working due to another change in the SDK structure, although selecting it manually would still work.

We have fixed it in this build: VisualGDB-6.0.103.5201.msi.

 

[support]

Hi,

We have not specifically tested VisualGDB with this board. However, if it comes with a functional toolchain and the gdb debugger (i.e. you can build and debug a project manually), you can easily point VisualGDB to the same tools and let it drive building and debugging for you,

[support]

Hi,

This would normally only happen if you change the VS color theme after using the memory window for the first time. If this is the case, please try simply restarting Visual Studio, and the colors should look normal next time.

[support]

Hi,

Sorry, not sure what you meant. If you believe VisualGDB is not working correctly, please provide complete screenshots showing every step of the wizard, and every other step you take (e.g. changed settings), including the final error message you get. Please ensure the screenshots are complete and uncropped. A single error message taken out of context is often not enough to suggest anything meaningful.

[support]

Hi,

No problem, we have reproduced and fixed the issue. Please try this build: VisualGDB-6.0.103.5197.msi

[support]

Hi,

Thanks, looks like the U5 port is using a couple of built-in functions that are not known to Clang and somehow trigger strange behavior.

We have added a workaround on the VisualGDB side. Please try this build: VisualGDB-6.0.103.5197.msi

[support]

Hi,

Sure, it should work just fine. Just make sure you are using the latest VisualGDB 6.0R3 and selecting the ST fork of OpenOCD.

[support]

Hi,

Thanks, we have reproduced and fixed the problem. Please try this build: VisualGDB-6.0.103.5196.msi

[support]

Hi,

You can actually override this by setting the SYSPROGS_TEST_REPORTING_PIPE environment variable to /dev/null. This will suppress the warning and will make the test framework work pretty close to the original unpatched version.

[support]

Hi,

Most likely, you are using incompatible versions of ESP-IDF, ADF and the toolchain. Please refer to this page for more information: https://visualgdb.com/documentation/espidf/#espadf

[support]

Hi,

It should not be an issue anymore. Either way, you can try creating a new C# console application (using .Net framework, not .Net Core) with the following code:

var rg = new Regex(@" \(WSL (\(|\))");
var ifaces = NetworkInterface.GetAllNetworkInterfaces().Where(iface => rg.IsMatch(iface.Name)).ToArray();

Does it find the one-and-only WSL interface?

[support]

Hi,

Sorry, it looks like the SMB connection between the Linux machine and Windows machine fails at some point, but it’s not something VisualGDB can automatically fix.

You can try using the usual white box / black box troubleshooting:

• Capture a WireShark trace of network communication between Linux and Windows and analyze it. It should give a good insight into the cause (some SMB request will be failing with an error), but getting to the bottom of it will be a very tedious task, trying to understand thousands of network packets.
• Alternatively, you can try simplifying the repro. Instead of a build, try reading all sources one-by-one. If it doesn’t trigger anything, do it from multiple threads. Try varying the number of threads, making pauses, etc. If it turns out that some particular pattern triggers the problem (e.g. more than X threads in parallel), you might be able to work around it by tweaking the build process.

[Author]

Posts