[support]

Hi,

Yes, sorry for the delay. We have encountered a few small issues with it and are currently fixing those. The current estimate is 1-2 weeks more.

[support]

Hi,

Sorry, this is a separate issue. The color for renaming suggestions is currently set regardless of the color theme.

The workaround is very straight-forward: please change it via Tools->Options->Fonts and Colors->Text Editor->Refactoring Suggestion.

[support]

Hi,

This looks like the Makefile got corrupt somehow. Could you please attach it so that we could quicky check for common problems?

[support]

Hi,

Sorry, we only provide support to users of our commercial products like VisualGDB. We will eventually release an updated version of SmarTTY that will include the fix, but we cannot give any timelines on that, sorry.

[support]

Hi,

Thanks, we will add this to our knowledge base.

Regarding ‘bt’, we use –stack–list–frames simply because it returns structured output that can be easily parsed; with ‘bt’ it could be tricky to separate arguments from function names, etc (e.g. when having namespaces and templates). If you believe using ‘bt’ makes a substantial difference, we could add a method to our extensibility API to replace the normal ‘list frames’ operation and you can experiment with writing a plugin based on the ‘bt’ command.

[support]

Hi All,

We have investigated this further and it looks like one of the recent OpenSSL releases broke backward compatibility in the logic related to RSA keys. We have rebuilt the libssh2 library using an older OpenSSL and it should work normally.
Please try this build: VisualGDB-5.2.11.1187.msi

[support]

Hi,

This might be some sort of plugin interference. Can you try doing the same on a different machine with a clean VS installation (or under a different user account on the same machine)? If the behavior is not reproduced, please try disabling other VS plugins. If this solves the problem, please try enabling them one-by-one to see which one causes the issue.

[support]

Hi,

Perhaps this is a different issue? Could you please attach a screenshot so that we could see if this can be reproduced?

[support]

Hi,

Most likely the problem you are observing happens because you run the ‘c’ command in the GDB console window instead of using the Visual Studio GUI to continue execution (F5). This breaks synchronization between VS and the GDB session and makes your debug session look it is hanging.

We understand that it might be confusing, so we have added support for parsing and redirecting the c, n, s and f commands to the upcoming VisualGDB 5.2 beta 3.

If you want to always load some extra symbols before debugging, you can add those commands to the Additional GDB Commands page of VisualGDB Project Properties or use the interactive mode of the Quick Debug command to run any custom commands you want in the console mode and then let VisualGDB take control once everything is set up.

[support]

Hi,

Thanks for confirming this. Looks like either something in your project prevents this optimization from turning on, or some other VS extension is requesting information about all threads.

Typically doing a single step even in a multi-threaded environment should result in something like this:

-stack-select-frame 0
^done
-thread-select 1
^done,new-thread-id="1",frame={level="0",addr="0x00000000004008d4",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeb48"}],file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="7"}
-exec-next
^running
*running,thread-id="all"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004008ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffeb48"}],file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="8"},thread-id="1",stopped-threads="all",core="0"
-stack-list-frames --thread 1
^done,stack=[frame={level="0",addr="0x00000000004008ef",func="main",file="LinuxProject3.cpp",fullname="/tmp/VisualGDB/f/PROJECTS/TEMP/LinuxProject3/LinuxProject3.cpp",line="8"}]
-stack-list-arguments --thread 1 0
^done,stack-args=[frame={level="0",args=[name="argc",name="argv"]}]

Could you please check if you get more than one “-stack-list-frames” command per step with this basic program and your toolchain:

#include <iostream>
#include <pthread.h>
#include <unistd.h>

using namespace std;

void *thread(void *)
{
    for (;;)
    {
        usleep(100000);        
    }
}

int main(int argc, char *argv[])
{
    pthread_t thr;
    pthread_create(&thr, 0, thread, 0);
    char sz[] = "Hello, World!";    //Hover mouse over "sz" while debugging to see its contents
    cout << sz << endl;    //<================= Put a breakpoint here
    for (;;)
    {
        usleep(100000);        
    }
    return 0;
}

[support]

Hi,

Perhaps the linker just reports the wrong function? Please try relocating ALL the functions from _divdi3.o in libgcc.a

[support]

Hi,

You can do that by creating another project with the new toolchain and copying the ToolchainID value from its stm32.xml file to the old project’s stm32.xml.

[support]

Hi,

Please try resetting the Visual Studio fonts & colors cache by deleting the HKCU\Software\Microsoft\VisualStudio\14.0\FontsAndColors\Cache key.

This should force VS to reload the correct colors.

[support]

Hi,

You can try using the tty command.

[support]

Hi,

Strange. Could you post the entire error message and a few lines above/below?

[Author]

Posts