[hamlatzis]

I've finally managed to make the emulator work and now can debug my game on it. Thank you.

As I don't have an actual android device, I've installed an experimental version of ICS on my HP TouchPad. It seams everything works all right. I can use the adb utility provided with the SDK to connect to the device with no problem. But I cannot debug from inside eclipse under windows on the actual device.

I created a second debug configuration for the device and selected my device in the Connection tab at the combo-box, but after a while I receive a message that eclipse cannot connect to the device. This is strange as I have no problem with the connection. Under a dos window using the adb command I can see I can connect, I even can shell into the device.

[Vinod Krishnamoni]

hamlatzis, on 19 April 2012 - 05:00 PM, said:

I've finally managed to make the emulator work and now can debug my game on it. Thank you.

As I don't have an actual android device, I've installed an experimental version of ICS on my HP TouchPad. It seams everything works all right. I can use the adb utility provided with the SDK to connect to the device with no problem. But I cannot debug from inside eclipse under windows on the actual device.

I created a second debug configuration for the device and selected my device in the Connection tab at the combo-box, but after a while I receive a message that eclipse cannot connect to the device. This is strange as I have no problem with the connection. Under a dos window using the adb command I can see I can connect, I even can shell into the device.

Hi,

Ok, so carrying on from where we left the discussion on http://blogs.arm.com...nts__1__st__15/ , you could search for a file called adb_common.py inside your configdb directory. The error message that you see ( "Error encountered when communicating... ) is coming from this file, from a function named adb_check(). So it looks like the sanity check for the adb connection is failing. This could be due to several reasons, I'll pass this on to the development team and see if I get any answers.

Vinod

[Vinod Krishnamoni]

Vinod Krishnamoni, on 25 April 2012 - 09:51 AM, said:

....I'll pass this on to the development team and see if I get any answers.
Vinod

Hi,

The device name in the DOS shell image that you posted looks weird due to the special characters. So we could try editing the scripts to make sure the scripts are handling this name correctly. For this, locate a script named deviceInfo.py in the configdb folder and modify the device variable to point to void (Modify the line that says "device = arg" to device = ' ' and repeat the device selection from the dialog). Please let me know the results.

Thanks
Vinod

This post has been edited by Vinod Krishnamoni: 25 April 2012 - 12:52 PM

[hamlatzis]

Vinod Krishnamoni, on 25 April 2012 - 12:50 PM, said:

Hi,

The device name in the DOS shell image that you posted looks weird due to the special characters. So we could try editing the scripts to make sure the scripts are handling this name correctly. For this, locate a script named deviceInfo.py in the configdb folder and modify the device variable to point to void (Modify the line that says "device = arg" to device = ' ' and repeat the device selection from the dialog). Please let me know the results.

Thanks
Vinod

Thank you Vinod, but it was only a partial fix.

As you can see from the first screen capture (also here http://dl.dropbox.co..._NewCapture.PNG) when selecting from the dropbox my device I get information regarding the device and the Debug button is enabled. Unfortunately (second screen capture http://dl.dropbox.co..._NewCapture.PNG) when I press the debug button or when I try to run the debug configuration from the Run menu it cannot connect to the device. With message: Error encountered when communicating with Android device: error: device not found.

At the beginning I modified the deviceInfo.py only on the file found at configdb folder. Also tried only to modify the script file under the C:\Android\eclipse\plugins\com.arm.debug.configdatabase.data.community_5.8.0.20111129_130858\Boards\Android\Generic folder and finally modified the script files under both folders. Similar results.

iosif

Attached File(s)

•  01_NewCapture.PNG (62.85K)
  Number of downloads: 5
•  02_NewCapture.PNG (158.12K)
  Number of downloads: 3

[Vinod Krishnamoni]

hamlatzis, on 25 April 2012 - 03:52 PM, said:

Thank you Vinod, but it was only a partial fix.

Hi,
It looks like we are on the right track and the problem appears to be the special characters in the device name and how the scripts handle them. As a workaround, please could you try changing device to point to void in the other scripts (run.py and setup.py) in the same folder and then try debug again?
For e.g in run.py, replace the below lines

if device != '' :
	adb_common.set_adb_param ('-s ' + device)

with

device = '' 

and

elif opt == "--device":
  	device = arg

with

device = '' 

Please let me know the results.

Thanks
Vinod

[hamlatzis]

Just changing the two scripts (run.py and setup.py) didn't do the job so I've searched all .py files and modified in similar way all occurrences of device to be empty. Again I think it partial worked.

The first time I select to debug the application I see that the application is installed on the device, the it is executed but then I get the message: "Failed to communicate with gdbserver at localhost on port 5000. No data received. Failed to connect to the device" But in the LogCat pane I see my debug output messages.

If I close the application and try for a second time then it seams it works, at some point the debugger stops at: 0x700057FD [debugger internal thumb] which I think is before entering my main application function. Unfortunately all breakpoints I have even though they are enabled don't work.

For instance I have placed a break point inside a function where I output the message "Should stop at this breakpoint", well I see output at LogCat but never stops at the breakpoint.

Did I do well by modifying all scripts?

Files I also modified apart from: (run.py & setup.py)

adb_common.py
push_pull.py
run_nostart.py
setup_nocopy.py

This post has been edited by hamlatzis: 26 April 2012 - 06:55 PM

[Vinod Krishnamoni]

hamlatzis, on 26 April 2012 - 06:54 PM, said:

Just changing the two scripts (run.py and setup.py) didn't do the job so I've searched all .py files and modified in similar way all occurrences of device to be empty. Again I think it partial worked.

Looks like you are getting close. Have you enabled USB debugging on the device by going into the settings? This link explains how to do it ( http://maketecheasie...vice/2011/04/06 ) but be aware that different devices have different screens to configure this option.That is something you could try. Let me know how it goes!

Vinod

[hamlatzis]

Yes I have it enabled. Also I have selected to give root access and allow to install applications also from other markets besides the Google one.

When I connect the tablet with the PC through the USB port at the status bar of the Android OS at the bottom I see two icons informing me that it's connected for debugging (bridge or something like this) and as mass storage device.

[AlbertCano]

Hi Hamlatzis,

After reading your comments, I dare say that the problem is that gdbserver doesn't attach to your app properly, either because the native application has exited before DS-5 can attach gdbserver to it -then is when you see ("Failed to communicate with gdbserver....")- or because gdbserver has attached too early (in JVM).

It is difficult to say, but my guess is that gdbserver tries to attach to your native library when this has finished.

For the first case you might need to add a delay before launching the Java native libraries (or inside your native library). For the second , you can edit the var SLEEP (in run.py and run_nostart.py), in order to add a delay between launching the activity and attaching gdbserver.

Once gdbserver is able to attach to the library loaded into memory you may be able to work with breakpoints and temporary breakpoints.

If you still have problems with gdbserver, it may be helpful if you could provide us with your app's status when the debugger fails, (open a windows terminal and execute >adb shell ps).

Albert.

This post has been edited by AlbertCano: 27 April 2012 - 02:59 PM

[hamlatzis]

AlbertCano, on 27 April 2012 - 12:30 PM, said:

......

For the second , you can edit the var SLEEP (in run.py and run_nostart.py), in order to add a delay between launching the activity and attaching gdbserver.

Setting the SLEEP variable to 1.5 sec fixed the error message that the debugger couldn't start my game, but didn't stop at any of my breakpoints.

AlbertCano, on 27 April 2012 - 12:30 PM, said:

Hi Hamlatzis,

For the first case you might need to add a delay before launching the Java native libraries (or inside your native library).

I tried different combinations of using sleep inside my code but nothing worked. I've added various sleep values only in the Java code just before calling the native code, same with just placing sleep only in the native code and tried having sleep both in the Java and native code. Nothing worked. None of the breakpoints fired.

The result from adb shell ps can be found in the two attachments

user = app_67
PID = 2493
PPID = 153
VSIZE = 480320
RSS = 38288
WCHAN = ffffffff
PC = 2aabc3e0 T
NAME = com.iosif.hamlatzis.Thalassa

Hope this helps.

Attached File(s)

•  capture.PNG (77.85K)
  Number of downloads: 3
•  ps_results.txt (9.76K)
  Number of downloads: 6

[AlbertCano]

Hi Hamlatzis,

Thanks, your ps output is very useful. It shows us that your application is stopped (T on column 8) but any gdbserver instance is attached to your process, which may imply that gdbserver has attached to your app but somehow afterwards has died.

DS-5 ships two versions of gdbserver: gdbserver-stat-7.1 a statically linked version of gdbserver and gdbserver-dyna-7.1 that is built to dynamically link against the libraries on the Android target. Please, if you have been using static, now use dynamic, or if you have been using dynamic, now try static,... you could also try the gdbserver shipped in NDK. From our experience in production devices, dynamic linked is more likely to work.

Thanks,

Albert.

[hamlatzis]

Thank you very much for your support. I've kept the SLEEP variable to 1.5 sec in the python scripts and used the dynamic version of the gdbserver and now all my breakpoints fire.

I need to find my bug now, but when I'll get more time I'll give it a try and get the SLEEP variable back to the default 0 sec.

In the mean time once more, thank you for your help