Forum Replies Created
-
Posts
-
Hi,
You might be able to ignore the xauth error (unless you are relying on X11 connection forwarding). The ‘file not found’ issue could be tricker. It would mean that the OpenSSH server confirms the file upload, but doesn’t actually upload anything under /tmp.
Please double-check that /tmp exists and is writable from the current user account. As a shortcut, you could also install gdbserver via ‘sudo apt-get install gdbserver’.
Hi,
It looks like VisualGDB is having trouble configuring the remote system to accept your public key.
Normally VisualGDB would open a new session, run the ‘pwd’ command immediately to find out the home directory, append “/.ssh” to it and run the following command:
test -d <SSH directory> || mkdir -m 700 <SSH directory>
If the command fails, VisualGDB would display that it cannot access the SSH directory.
You can work around this by simply unchecking the “setup private key-based authentication” checkbox in the SSH setup window or by double-checking the target directory structure and ensuring that the account you are using with SSH has the <home>/.ssh directory.
Hi,
Sorry, not sure what you meant. Could you please share an error log showing what exactly is broken?
Hi,
Sorry, the profiler is current ARM-only. ESP32 supports a technique similar to our fast semihosting, so long term we should be able to support profiling on ESP32 as well, however we don’t have any specific plans for this yet.
Hi,
Thanks again for checking this. Looks like the main thread’s call stack is missing one more step – right-click on the ntdll frames (and other unnamed ones) and select “Load Symbols”. This will unwind the stack correctly and will display the meaningful information.
Based on your description, it is starting to look like a bug triggered by some combination of display drivers, resolution, etc, so it might be tricky to solve it on our side. You might be able to avoid it by setting the comment size limits via Tools->Options->Text Editor->C/C++ (VisualGDB)->Advanced->Code Completion->Max. following comment lines/Max. preceding comment lines.
Hi,
No problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2268.msi
It adds support for $(SolutionDir) and $(SolutionPath) for ESP-IDF projects (only when built from Visual Studio).
Hi,
Thanks, this looks like the hang happens outside the VisualGDB (or any other .Net-based components), which is strange as most GUI-related object in Visual Studio is based on .Net.
Please try attaching both ‘managed’ and ‘native’ modes and then recheck the main thread stack (you don’t need to attach other thread stacks as they are not related to the hang).
Hi,
There is no special GUI option for that, however you can accomplish it by adding “-Wl,-Bstatic -l<library name>” to the “Additional linker inputs” field. If this doesn’t work, please let us know your project type (MSBuild/Make/CMake/QMake) and we could suggest a better option.
Hi,
The IDF_PATH should actually be handled by VisualGDB directly. Normally it takes the list of IDF checkouts from the toolchain directory, however if you are keeping a custom checkout together with your codebase, we could add a per-user list of IDF checkouts. So once you configure (once per development machine) that the “com.yourcompany.idf-patched” is located in c:\projects\idf, VisualGDB will find it automatically from all projects.
Hi,
This might be caused by some combination of your VS version, video driver and the display resolution (that would explain why it doesn’t trigger on our side).
We could add a setting that will limit the maximum amount of lines shown in the popups if this helps. However before that, please try attaching to the VS instance again and enable the “Show external code” option in the call stack. This should show what exactly the main thread is doing when VS is hanging.
Hi,
Currently we do not have plans for updating the Beaglebone tutorial as most of the steps shown in the current tutorial should still apply to the current version. That said, if you could let us know what exactly you found confusing/outdated, we should be able to update the tutorial to ensure it does not misdirect other readers.
Regarding the program location, by default, VisualGDB will upload all the sources to the specified location on the Beaglebone (the default path is /tmp/VisualGDB/…) and build it there. Normally the built executable would be located in the <uploaded source directory>/Debug or <uploaded source directory>/VisualGDB/Debug folder.
You can find out the exact path by starting a debug session and opening the GDB Session window in the All GDB Interaction mode. The first line should show the GDB command used to start debugging; this command should contain the full path to the built executable.
Hi,
Sorry for the inconvenience. This looks like something that was fixed in the recent Nordic BSP hotfix (14.2R2). Please ensure you install the latest version via Tools->VisualGDB->Manage VisualGDB Packages.
Hi,
We have quickly tried reproducing this, however unfortunately could not get anything similar. Could you please try attaching another VS instance to the hanging one (ensure Managed mode is enabled) and check the call stack of the main thread when it’s hanging? If it contains anything from the VisualGDB assemblies, please let us know the exact build number (from the About VisualGDB window).
