Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Adobe AIR Development

Reply
Contributor
Posts: 20
Registered: ‎02-05-2011
My Device: Not Specified

Re: Command Line Debugger Issues

Hi,  I have reinstalled the simulator trying out the diffrent network options, with no luck.  I am now using the network setting 'Bridge' and have selected my airPort network.

 

Im using an iMac osx 10.6.5

Playbook sim : BlackBerryPlayBookSimulator-0.9.2

Installed the Sim using VMware

 

My command line is somthing like this:

 

/Applications/Adobe\ Flash\ Builder\ Burrito/sdks/blackberry-tablet-sdk-0.9.2/bin/blackberry-airpackager -target bar-debug -connect 10.0.1.4 -package ${app-naame}.bar -installApp -launchApp ${app-naame}-app.xml ${app-naame}.swf (50+ assets here) -device 10.0.1.6 -password *****

 

My playbooks ip is : 10.0.1.6

My ip : 10.0.1.4

 

ifconfig output :

 

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether c4:2c:03:07:9e:21
    media: autoselect
    status: inactive
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
    lladdr e8:06:88:ff:fe:eb:ae:fe
    media: autoselect <full-duplex>
    status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether d8:30:62:54:cb:28
    inet6 fe80::da30:62ff:fe54:cb28%en1 prefixlen 64 scopeid 0x6
    inet 10.0.1.4 netmask 0xffffff00 broadcast 10.0.1.255
    media: autoselect
    status: active
vmnet1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:50:56:c0:00:01
    inet 172.16.41.1 netmask 0xffffff00 broadcast 172.16.41.255
vmnet8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:50:56:c0:00:08
    inet 172.16.74.1 netmask 0xffffff00 broadcast 172.16.74.255

 

 

Note - If I run a diffrent app using Flash Burrito and debug with that, I can see trace ststaments.

 

Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Command Line Debugger Issues

[ Edited ]

The ironic thing is that in order to try to reproduce the problem, after shawn's post about it not being network issues, I've got my machine doing the same thing.

 

All I did, after weeks of it working fine, was to terminate my debugger and run an app which wanted to connect to it.  After a timeout (20s or so?) with the splashscreen showing, I get the same dialog.  Only now it won't connect even after I enter the correct IP (though I can connect to port 7935 on my host machine using telnet from my host machine).

 

Connecting to the simulator using SSH, and running Python2.7 to let me establish a socket connection back from the simulator to port 7935 on my host machine also results in a failure.  I believe that proves, at least with my own setup, that there's something defective in the simulator, though it does seem to be network related (in spite of there not being any "network issues" in terms of my own setup).  

 

Basically the simulator can get itself into a state where it is unable to establish connections to your host machine.  I can connect to other addresses (even on the net), but not my own host.  Will continue investigating...


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Command Line Debugger Issues

Okay, it took me an hour and a half, but I got it working again.  Unfortunately what I did may not be directly related to my success.

 

For background, I originally (now that I recall) had the same problem with the "unable to connect" dialog in the simulator showing up, even with everything correct.  At the time, I was experimenting with various things including my own Python-based (and trivial) debugger listening on port 7935, so I didn't pay it that much attention.  

 

I also have a router serving up address via DHCP so I had switched to Bridged mode a while back, and used that for a long time.

 

Since then, I'd used my laptop for PlayBook development while offsite, so I had switched back to NAT mode.  That didn't seem to cause any trouble, and I'd left it there even when I got back.

 

So everything's been running fine in NAT mode, with my own debugger (and fdb, the rare time I used it).  Until earlier today when I attempted to reproduce the problem.  I don't know if all I did by terminating my debugger was to cause the simulator to fail to connect just the once.  In any event, I was stuck, like you guys.

 

I spent 1.5h going through many combinations, trying VM reset, VM power-off, disconnect and reconnect network in VM, entering the wrong address in the dialog, then the right one, trying with and without the debugger running, trying while connected via SSH, and so on.  Nothing was working and I was getting pretty fed up (like you guys must be! :-)  ).

 

The one thing I hadn't tried was switching back to Bridge mode, so I did that.  I think I then not only terminated the simulator but also exited from VMware Player before restarting it.  I waited until everything was back up, then connected in another window with blackberry-connect (not that I think that was involved but I like to do it as I use SSH frequently and this way I could be sure the networking was set up correctly).  At that point I carefully rebuilt my app with the correct -debugHost setting for the new network (i.e. my "real" IP address for the host, not the NAT), and redeployed. 

 

And it connected immediately to the debugger.

 

I really hope that helps someone.  I'll now try switching back to NAT mode, and will see whether I can connect again.  If I can, it doesn't really make much sense to me other than that there must be some persistent networking info in the simulator/QNX (which seems possible) which can get messed up and, at least for a while, prevent it from connecting out to some networks (which not totally preventing network communications).


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Highlighted
Developer
Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: Command Line Debugger Issues

Okay, when I switch back to NAT mode, at first I couldn't even connect to install my app.  I was getting this error back, which I'd never seen before:

 

 

blackberry-deploy -installApp -launchApp -debugHost 192.168.40.1 -devMode -device 192.168.40.129 -password x -package MenuTest.bar

Error: Cannot connect: Connection to https://192.168.40.129 refused. You may have to reboot the target.

 I pinged the device and got a response.  

 

I tried connecting with blackberry-connect and it connected.  

 

When I tried the deploy again, it worked.  I assume it was a temporary problem caused by attempting to connect too quickly after startup, or just a one-off glitch.

 

 

When I installed the app, after a timeout it shows the dialog saying it can't connect to the debugger.

 

This time, in the dialog, I entered my real IP address, which I was using with Bridge networking before.  The debugger got a connection immediately and the app ran.  That's not overly surprising, since even with a NAT address, the PlayBook should be able to connect out through my machine, through my router, and back to my machine on the real network address.  (I don't think it actually works that way... I think the host machine's routing ability just recognizes the attempt to connect to its other address and allows it, or maybe it's VMware that can manage that.)

 

Given that result, I tried building/deploying with "-debugHost 192.168.7.154", which is my real host address, not the NAT one.  It connected immediately again.

 

So the moral, at least for me, is that sometimes the simulator can get "stuck" (when in NAT mode) so that it can't/won't connect to your host IP on the NAT network.  Try using your real host IP instead (the one for your Ethernet or wireless connection) and see where that gets you.

 

In case it's relevant, I'm using Windows 7.  Some behaviours could well be different on the Mac.


Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!