[support]

Hi,

The Edison toolchain might require an explicit “–sysroot” argument. Please try specifying it via additional command line flags for both compiler and linker (see the toolchain documentation or included examples for the correct sysroot value).

[support]

Hi,

Thanks, according to the stack trace, VisualGDB was stuck waiting for a response from the Linux machine while trying to close an SSH connection. If you run into this problem again, please try updating your SSH server or try a different network connection (e.g. this could be caused by packet loss).

[support]

Hi,

Unfortunately, VS registry can get corrupt in many different ways, so one specific instance won’t be of much help. You could try getting a diff of the .reg files from the old and the new key and quickly check if there is anything obviously wrong there (or send the diff to us if the amount of changes is relatively small), but unless it gets obvious from the first glance, investigating it further won’t be worth the time.

[support]

Hi,

Please double-check that the .S file is actually compiled with the -ggdb switch (so that gdb can get debugging information for it). If it does not help, please try repairing breakpoints via VisualGDB breakpoint repair button in the GDB Session window.

[support]

Hi,

Please try referencing the “config” variable from your code so that the linker does not discard it as unused. Alternatively you can try using the KEEP() statement in the linker script file and attribute__((used)) in your code.

If it does not help, try enabling the map file generation via Linker Settings and check the map file to see where exactly the linker placed your variable.

[support]

Hi,

The behavior you are describing would make 100% sense if the sleep loop was infinite (the optimizer would eliminate the rest of the code), but if it’s limited to 100 iterations, it should not happen.

Please try pressing the ‘diagnose breakpoint problems’ button in the GDB Session window to automatically diagnose path mapping issues.

[support]

Hi,

Thanks, this looks like the hang is related to VisualGDB. Could you please let us know the exact VisualGDB build (from VisualGDB.exe file properties) so that we could pinpoint this further?

Please also try manually killing the CppEngineHost.exe process next time the hang happens. If the hang is related to the Clang IntelliSense engine, this should help.

[support]

Hi,

The file is only needed to setup non-Clang IntelliSense; if you don’t get any other errors, you can simply ignore this problem (and/or remove the reference to the file via VS project properties -> NMake settings -> Forced includes).

[support]

Hi,

You don’t need to delete the VisualKernel folders/keys, only the Visual Studio ones:

• C:\Users\<user>\AppData\Roaming\Microsoft\VisualStudio\14.0
• C:\Users\<user>\AppData\Local\Microsoft\VisualStudio\14.0
• HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0
• HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config

We recommend renaming the folders/keys before you confirm that it solves the problem in case you accidentally delete something critical.

[support]

Hi,

When you try to insert a breakpoint in a running program, VisualGDB sends a Ctrl-C signal to the gdb and it response gdb tries to halt your program. If anything on this path is broken, settings breakpoints in a running program won’t work.

This could be caused by your program altering the handling of SIGINT or some system-wide settings. If it only happens with one project, we would recommend placing an infinite loop in main(), checking that ‘Break all’ still works, and then moving the infinite loop around to find the code that breaks the Ctrl-C handling.

[support]

Hi,

We have double-checked the window. The GUI thread should have the following attributes set:

• Both Category and Name should read “Main Thread”
• The Managed ID should be 1

In order to get past the “external code” issue, please right-click in the Call Stack window and select “Show External Code”.

Alternatively you can simply select Debug->Save Dump As, upload the dump file (~1GB) to dropbox and share a link so that we could investigate it on our side.

[support]

Hi,

This can actually be changed via VisualGDB Project Properties (we made it into a separate setting to simplify troubleshooting). We normally mention this in our tutorials; if you followed one that does not mention this setting, please let us know and we will update it.

[support]

OK, this is starting to look like a corrupt VS installation. Please try installing VisualKernel from another user account and check if it works. If it does, please try renaming/removing per-user Visual Studio folders and registry keys so that VS can reinitialize its environment and then reinstall VisualKernel again.

[support]

Hi,

No problem. Please follow the steps below:

1. Ensure you have exactly 1 instance of Visual Studio running
2. Start another VS instance
3. Select Debug->Attach to process
4. In the process list select devenv.exe (Visual Studio) and in the “types of code to attach” select “automatic”.
5. Click “Attach”
6. Click Debug->Break All
7. Open the Debug->Windows->Threads window, locate the GUI thread and double-click on it
8. Open the Debug->Windows->Call Stack window, select all frames and copy-paste them here

[support]

Hi,

If it was not VS2017, we would recommend attaching another VS instance to the hanging one and checking the call stack of the main thread. This should explain what exactly is causing the delay.

[Author]

Posts