[ket]

Hi,

Which output do you mean here, GDB Session? It already has a pause auto-scrolling button.

[ket]

Hi,

Thanks for the suggestion. We will make a tutorial on Qt development on Android.
While we look into this, feel free to ask about any issues you are having getting Qt development on Android working with VisualGDB.

[ket]

Hi,

The gdbserver is probably not running when you try to kill it, the –quiet flag hides all errors, so that is why no informative error message is shown. Try making a short script and running it instead, make it always return 0, no matter whether killing the gdbserver failed or not.

The usual F5 start debugging button works for all projects, so that is why the usual “Start Debugging With GDB” button is not duplicated in the VisualGDB toolbar. The special Android debugging button uses the same icon, but is named differently.

[ket]

Hi,

First of all, try updating your gdbserver, the 2009 year version is probably a bit old. If your gdb is as old, try updating that as well.

The problem with the predebug command can be the working directory, try clearing that field. The GDB log is not shown as debugging did not even start GDB. Look in the Output window for the predebug command outputs. Change the filter to show VisualGDB Launcher output. The debug app startup button is grayed as it is only used for Android app projects, it is a special debug option allowing to connect gdb gracefully while pausing the Java code execution.

[ket]

Hi,

Please download and install VisualGDB version 4.1r4, we changed the source cache to depend on the variable %LOCALAPPDATA% there. So, the source cache is stored per user but the project file is not dependent on a particular user’s directories.

After installing the new version, go to VisualGDB Project Properties, change something in Makefile settings and press on Apply to rerun the toolchain tests. You can then check in the usual VS settings’ NMake page whether the directories now depend on %LOCALAPPDATA%.

[ket]

Hi,

Normally it is no problem to have JDK installed in Program Files (x86). It should give no issues as Java based tools are fine with spaces in paths. It would take a special set of circumstances for the errors you have experienced to appear.
You could try to have JDK still in Program Files but specify the JDK path in VisualGDB using %PROGRAMFILES(x86)% . Does that work?
What exact fix in VisualGDB would you like to have?

[ket]

Hi,

For the first issue, if you have a disassembly window open, then close it. That usually makes gdb query those strange hex symbols. There is no way to stop the “GDB Command Timeout” window from appearing as it only appears if there are problems with commands taking too long. The window will close automatically if the command manages to complete, if not then it provides the user a way to abort the command or even stop debugging. If the window would not appear, then in the case of commands never completing, debugging will hang indefinitely with no info on why.

As for the second issue, normally when you stop debugging as the gdb exits (gdb command -gdb-exit) the gdbserver is also killed. If it happens all the time, it can be specific to your Linux, gdb or gdbserver version that it is not killed. You can add an action to kill the gdbserver manually to either pre or post GDB actions (Custom debug steps page in VisualGDB Project Properties). You can also try killing gdb by setting the stop debugging action differently (bottom of GDB Settings page in VisualGDB Project Properties). Also, you switch to using a custom gdb stub from Debug settings (“start gdb in the following mode”) to specify additional gdbserver settings.

[ket]

Hi,

The strange line in the output is the following:

[dx] 'C:Program' is not recognized as an internal or external command,

As the only tool installed in Program Files is JDK and it is the only tool that is not up to date, try downloading and installing the latest JDK (32-bit version as Android requires it). Make sure you reference it also in VisualGDB Android settings. Check that you do not have any conflicting JAVA_HOME environmental variables set in your system. Then try rebuilding your project, clean it first, manually delete the build.xml and local.properties from the project’s directory if cleaning does not do that.

If this does not help, try running Visual Studio as an admin as it could also be a user access rights issue.

[ket]

Hi,

Android virtual devices are inherently slow, we always advise to use real Android devices for most of the development process. That said, there are a few ways to speed up virtual devices.
Try using Intel HAXM, we have a tutorial on how to set it up. Also the newer Android platform AVDs are slower, i.e. versions 1.x and 2.x are faster than 3.x or 4.x.

As for the trial expiry, you can email our sales team to ask for a trial extension code if you need more time to evaluate VisualGDB.

[ket]

Hi,

It still looks to be a tool related error as it is the build.xml that comes with Android SDK that reports errors. What versions of Java JDK, Android SDK, Android NDK, ANT do you have installed and what are their installation directories?

You can also try to run ant with verbose mode to get more details on the error. In Visual Studio go to the Output window and find the build line that runs ant.bat in your project directory. Run the same command in your project directory but also add -v to it.

[ket]

Hi,

It looks like there have been some changes in the Android build system. The issue here is not how the library is referenced in the app project, that code is fine. Building a shared library from a static library does not work any more, it creates an empty library hence the undefined reference error. To fix this replace the Android.mk content of the library project with the following:

# Generated by VisualGDB

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE    := AndroidLibrary1-static
#VisualGDBAndroid: AutoUpdateSourcesInNextLine
LOCAL_SRC_FILES := AndroidLibrary1.c
LOCAL_C_INCLUDES :=
LOCAL_STATIC_LIBRARIES :=
LOCAL_SHARED_LIBRARIES :=
LOCAL_LDLIBS :=
LOCAL_CFLAGS :=
LOCAL_CPPFLAGS :=
LOCAL_LDFLAGS :=
PERSISTENT_SRC_FILES := $(LOCAL_SRC_FILES)
include $(BUILD_STATIC_LIBRARY)

include $(CLEAR_VARS)
LOCAL_MODULE    := AndroidLibrary1-shared
LOCAL_SRC_FILES := $(PERSISTENT_SRC_FILES)
include $(BUILD_SHARED_LIBRARY)

Also, now if there is a shared library target defined somewhere in Android.mk then somehow the static target does not get built. So to still build both static and shared libraries from the same code add the following line to the library project’s Application.mk:

APP_MODULES := AndroidLibrary1-static AndroidLibrary1-shared

We will include a fix to these issues in our next r release and edit the Android library tutorial to reflect the changes.

[ket]

Hi,

If the build fails, then add the sqlite3.h directory to include directories in makefile settings.

If only IntelliSense complains about the include being not found, then look on the IntelliSense directories page in VisualGDB Project Properties, the directory should probably already be there (it is probably /usr/include). If it is not there, then add it, otherwise select the directory and reload it. As you added header files with the sqlite3-dev install, the locally cached headers for IntelliSense need to be updated.

[ket]

Hi,

When you installed sqlite3, did you install the development package libsqlite3-dev?

[ket]

Hi,

We have released a fix for the breakpoint setting issue. You can download the r3 release from our download page at http://visualgdb.com/download/ .

Do you mean this name is mangled “_ZN17BlbsUploadUtility19CatalogMappingStageER14RWDBConnectionRK9RWCStringRK10RWDateTimeS7_S4_RiR6EtlLogS4_R11BlbsContextRS2_” ? That is completely normal, gcc mangles the function headers during building using c++filt to create unique function names. For example the mangled name demapped through c++filt is “BlbsUploadUtility::CatalogMappingStage(RWDBConnection&, RWCString const&, RWDateTime const&, RWDateTime const&, RWCString const&, int&, EtlLog&, RWCString const&, BlbsContext&, RWCString&)”.

[ket]

Hi,

Please check that the values for LOCAL_SRC_FILES and LOCAL_EXPORT_C_INCLUDES make sense for your project (the working directory is just the project directory of the app, $(LOCAL_PATH) is “jni”), both need to be appropriate relative paths.
Look in the Output window, if the LOCAL_SRC_FILES value is wrong or the built library cannot be found, then Android NDK will show a warning in the build output with the translated path.

Also note that in VisualGDB version 4.0 and above you do not need to modify the Android.mk manually, as long as you reference the project VisualGDB will modify the makefile automatically during build. It may still be worth checking the Android.mk changes after building for example if you would prefer to use static over shared libraries.

[Author]

Posts