Forum Replies Created
-
Posts
-
Hi,
Sorry for the delay, unsuccessfully tried to reproduce it on our side. This looks like some strange SSH protocol bug. In order to investigate it further please try the following:
Once debugging has been started please go to the SSH session window, click on the hyperlink to start a session, then run GDB manually in the session:gdb
then set a breakpoint manually, run the program and try issuing the ‘target’ command manually:
b main
r
targetPlease let us know if the output of the ‘target’ command comes normally, or if you experience the same problem in the manual mode. If in the manual mode the problem does not reoccur, please rerun GDB in the MI mode:
gdb –interpreter mi
Although GDB output will look differently now, it will still accept normal commands. Please try running the same 3 commands to see if the ‘target’ output is incomplete.
If you manage to reproduce the problem in the manual mode, please click at the console symbol inside the GDB session window. A multi-tabbed SSH client will be launched. Please open 2 tabs, try reproducing the frozen ‘target’ command in one tab and then see if typing anything in another tab affects the first tab.
Hi,
Oops, sorry for that. Please provide us with the following information to pinpoint your problem:
1. Does the problem occur on every debug session? If not, how frequently does it occur?
2. Does the “timeout” dialog automatically disappear after 1-10 seconds? If this is a bug of LibSSH2, we have a safety mechanism that should automatically resolve such hanging within 1-10 seconds.
3. Does invoking “info target” manually via the SSH Session window cause the same bug?Hi,
Currently this is not possible directly. You can put a breakpoint at the end of the main() function to achieve a similar result.
Using scanf() or cin should normally work. Please send us an archive with an entire test project (including the source code and the Visual Studio project files). If this is a bug of VisualGDB, this will help us to reproduce and fix it.Hi,
Please go to Visual Studio Configuration Manger (click on the debug/release switch on the toolbar) and remove the “build” flag for the projects you don’t want to build.
Note that you can create as many solution configurations as you want all having different project sets enabled.You can also configure Visual Studio to prompt before auto-building the projects when you start debugging.
Hi,
Normally the Python include files are located in a Python-version subdirectory (e.g. /usr/include/python2.7/Python.h). Thus you need to add it to additional include path.
This can be done by setting the INCLUDE_DIRS variable inside flags.mak. E.g.:INCLUDE_DIRS := /usr/include/python2.7
If you are using a cross-compiler, the path will be:
CROSS_SYSROOT := C:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot
INCLUDE_DIRS := $(CROSS_SYSROOT)/usr/include/python2.7Thanks for the kind words. We do our best here at Sysprogs to make complex debugging scenarios easy and enjoyable.
-
As for the cross-compiler, both options have pros and cons:
- Building big projects with a cross-compiler is usually faster, as your computer is much faster than the Raspberry PI box. However, it will require synchronizing includes/libs and might cause strange bugs if the libraries inside the cross-compiler and on the Raspberry PI get out of sync.
- Building and running GDB directly on Raspberry PI should work out-of-the-box for most cases, but it may become annoyingly slow for big projects with many source files.
- If you are building an app that comes with a configure script that should run on Linux, you cannot use the cross-compiler unless you want to set the MSYS environment manually (which will still impose some limitations).
Bottom line, VisualGDB fully supports both options, the choice is yours depending on what’s more important to you…
Thanks for this bugreport. Looks like it’s our bug related to using the build server.
Please use SSH instead. The SSH support is a new feature introduced in VisualGDB 3.0 and we haven’t updated all our tutorials yet.Edit: fixed the bug and replaced the Beta2 distro. Thanks again for reporting it.
Hi,
When using a cross-compiler for Raspberry you need to copy any additional include files from the /usr/include on the Raspberry box to C:SysGCCraspberryarm-linux-gnueabihfsysrootusrinclude. Then the toolchain and the IntelliSense will recognize them correctly.
You can use SmarTTY, our free SSH client to quickly download the entire include directory into the toolchain directory.
Hi,
Thank you for your bugreport. Please provide us with more information so that we could pinpoint the problem:
1. Which OS/VS version are you using?
2. Are you selecting the default settings or changing something (e.g. setting up SMB shares)?
3. Is your WIndows project directory writable.
4. Is your Linux project directory writable?
5. Are the remote file/directory browse dialogs working in the wizard (e.g. when you try to change the source directory)?
6. If you enable the advanced wizard mode and disable importing of IntelliSense directories, will the problem still persist?As a last resort, please set the following registry value:
HKCUSOFTWARESysprogsVisualGDBSettingsExceptionReportDir = c:tempvgdbEnsure that c:tempvgdb exists and is writable by the user account used to start Visual Studio.
Then try reproducing the problem. If VisualGDB encounters any internal errors, it will create report files in c:tempvgdb. Please send us those for further diagnostics.Hi,
Thanks for reporting this. Fixed in Beta 2.
http://www.visualgdb.com/download/Hi,
Could you please send us your .vcprojx file and the .filters files so that we could reproduce and fix your problem?
There was a bug in v2.7 that could cause this, however it was fixed in v3.0.Hi,
Yes, the bug is caused by the ‘ps’ command producing slightly different output from the one on most of the Android devices.
We have fixed this in the upcoming VisualGDB 3.0 release. We are planning to release the beta (also supporting vs-android integration) at the end of this week.
