Forum Replies Created
-
AuthorPosts
-
support
KeymasterHi,
The Android GDB provided by Google is VERY slow. If your library size is 18MB, it might take several minutes to load the symbols. When VisualGDB displays this warning, the operation is still running in the background, so the window will disappear after some time.
support
KeymasterHi,
For the first month, yes. If you upgrade later than 1 month after buying, the upgrade cost will include additional fees for extending your support period that are proportional to the time difference.
support
KeymasterHi,
Essentially, the Custom Edition unlocks the “Full Custom Configuration” menu in the Project Wizard. If you have not used it so far, Network Edition should suit your needs.
Below are the detailed answers to your questions:
1. With the Network Edition VisualGDB will only do the following to build your project:
a. Copy source files
b. Run a command line you have specified
When you debug a project it will also run 1 command line that you provide.With custom edition you can specify command lists (e.g. copy multiple directories, run some commands before/after GDB and so on). Essentially, you can do all of it with your custom script and tell the Network Edition to run it. However, if you plan to do those things frequently, the Custom Edition might save you some time by automating it.
2. “Start GDB interactively” refers to the “Start custom GDB session” in the Debug menu in Visual Studio. It is only useful if you want to experiment with various GDB settings without modifying project settings.
3. “Multiple build machines” refers to the full-custom configuration. With the Network Edition “build project” means “transfer files and execute 1 command line specified by you”. The command line can be arbitrary and can invoke any tools you wish. With the Custom Edition you could use VisualGDB functionality to run several commands on different machines (e.g. build your app on Linux machine A, then transfer it to Linux machine B and run GDB on machine B).
4. Custom GDBSERVER-like setup means that VisualGDB will
a. Run your program that opens a connection on some port
b. Run GDB so that it attaches to that port
c. When GDB exits, VisualGDB will run another command line to stop the first programYou can script all of that yourself as well and let VisualGDB just start your script…
5. Yes, you can assign shortcuts to VisualGDB commands by using Visual Studio Options window as described on the FAQ page: http://visualgdb.com/support/faq.php
If you have any further questions, feel free to contact support or ask on the forum.
support
KeymasterHi,
Based on the log you have provided, some data gets lost between your PC and the Android device, so that GDB cannot really debug it.
This might happen if you are running VisualGDB inside a VM or if it can be also caused by a buggy device driver.Are both devices using the same driver (according to Windows device manager)? Is there any software on your computer that might try to access the Android device on its own and thus interfere with debugging?
November 1, 2012 at 13:55 in reply to: "Object reference not set to an instance of an object." #2362support
KeymasterThat is strange. Please send us an archive containing the following files from your project/solution:
1. *.sln
2. *.vcproj
3. *.vgdbsettingsThis will help us reproduce the problem on our side and provide you with a solution.
support
KeymasterHi,
In order to debug your Lib VisualGDB would need 2 things:
1. An AndroidManifest.xml file so that it can know which app to attach to.
2. The libraries with debug symbols put into obj and libs folders, so that VisualGDB can set breakpoints and find code in source files.You can emulate both by copying the files to the project directory:
1. Copy AndroidManifest.xml file to the directory of your lib project (or to the directory that you specified as a “build directory” when creating the project)
If this does not solve the problem, please attach your AndroidManifest.xml here.
2. Copy your .so file tolibsarmeabi
3. Copy your .so file with symbols toobjarmeabi Once this is done, the library project should be debuggable the same way as the app project (including co-debug with Eclipse).
If you have any further difficulties, feel free to post here or contact support directly.support
KeymasterHi,
1) Sure. Here’s a tutorial how to do that: http://visualgdb.com/tutorials/android/codebug/
2) Unfortunately, the current version only imports the files from the project directory. Thanks for your feedback, we have put this feature request to the v2.8 plan.support
KeymasterHi,
Please use the VisualGDB Project Properties window to make a new configuration. It copies the file correctly.
support
KeymasterHi,
The Android emulator is the answer here. It is unbelievably slow compared to the actual Android devices. However, note that you would need an actual Windows machine (not a VM) to debug a physical phone or a tablet, as the Android USB driver does not work well with VirtualBox/VMWare.
support
KeymasterHi,
Building from Eclipse works, as Eclipse uses a separate eclipse-specific build system plugin, while VisualGDB relies on Apache ANT (official command-line build tool for Android).
Looks like your build.xml file is either generated by an old version of Android SDK or has been replaced by some other tool.
Please try deleting it and rebuilding the project. VisualGDB should rebuild the build.xml file automatically.If the problem persists, please attach the log of the first build (after deleting build.xml) and specify your Android SDK version.
You can also try deleting/renaming the build.properties file.
support
KeymasterStrange. Please attach your build.xml file here or send it to support@sysprogs.com so that we can try to reproduce your problem.
support
KeymasterHi,
After setting the environment variable you need to restart Visual Studio (or better restart your computer) to get the environment variable propagated.
The problem seems to be quite common for Android SDK (e.g. see here: http://blog.klacansky.com/matter-code/ant-taskdef-class-com-android-ant-setuptask-cannot-be-found).
Could you please attach the D:GabySoftGCodeHexLogicAndroidbuild.xml file here?support
KeymasterHi,
The build problem is caused by the ANDROID_SDK_ROOT environment variable. Please go to System Settings, Environment Variables and set a new Environment Variable for the current user:
Name: ANDROID_SDK_ROOT
Value: directory where you have installed Android SDKNote that VisualGDB 2.8 will provide ANDROID_SDK_ROOT automatically and won’t require this trick any more.
Regarding the breakpoints, there are numerous breakpoint bugs in ndk-gdb and VisualGDB provides workarounds for most of them. If it does not work in your case, please do the following:
1. Open VisualGDB Project Properties (right-click on the project in Solution Explorer).
2. Go to GDB Settings tab.
3. Check the “Log all interaction with GDB” checkbox.
4. Start debugging. Try setting breakpoints.
5. In the GDB Session window run the following commands:info shared sharedlibrary
6. Try setting your breakpoints again.
7. Exit debug session.Then please send all .log files from your project directory to support@sysprogs.com so that we can diagnose your problem further.
support
KeymasterHi,
The portable WinCDEmu uses a special driver build that does not rely on .inf files.
Try the new experimental build: http://wincdemu.sysprogs.org/portable/PortableWinCDEmu-3.6.exesupport
KeymasterHi, guys. Sorry for the delay, got far too many things to do.
Try this build: http://wincdemu.sysprogs.org/portable/PortableWinCDEmu-3.6.exe
Note that it has not been through the usual testing cycle, so feel free to report any bugs… -
AuthorPosts