BUG Community

I just received my Bug and installed the SDK.
That all appears to be working correctly.
However, i am having trouble when trying to run the Virtual Bug.

My system is Atom N270 1.6GHz, 2GB Ram, Windows XP, SP3, 160GB HDD

I tried creating a new application with the following steps:

1. Click New Bug Project
2. Name it and click Next
3. Click on Start Virtual Bug
4. Dialog appears for a second then closes; a lot of output in Console window as Virtual Bug launches…then….
5. Nothing happens…
Console output ends with:

Back in the new program dialog, it just sits there (not sure what is supposed to happen); i still cannot select services; nothing shows up in the target bug frame; no other windows open…
6. If i click Start Virtual Bug again it complains that one is already
running.

If i try to launch a virtual bug from the toolbar in the IDE…it creates the console output and then nothing. no windows open, nothing changes…

Not sure if this is related…down in the lower right corner of the IDE is a progress bar indicating that something is trying to connect to my local host at port 8082. It never completes. If i click on it to open the progress window, i see 100’s of ‘Testing Connection’ tasks running, but nothing ever connects. If i try to ping the above address in my browser…it cannot find any such page. so it looks like some sort of server service is failing to run.

I did several searches of the forums and cannot find anything that points to this kind of problem.
I have tried turning off all virus checkers and firewalls…no effect.
Tried several versions of the SDK…no difference
Tried killing all task bar applications…no difference

Thanks for any suggestions for where to look.

Hi philba,

Can you open the PDE Error log view and tell me what it says when you try to launch the Virtual BUG?

Window->Show View->Other->PDE Runtime->PDE Error Log

Also, could you tell me which version of the Dragonfly SDK you’re using?

Help->About Eclipse SDK>(click on the dragonfly logo in the resulting window)>Version field in the resulting window. In the form field at the top.

Thanks.

Sorry John,\
This site won’t let me post the error message…it complains that it cannot let me post web addresses until i have been a member for at least one day…or some such nonsense.

I will try to clean it up enough to get past the filter…

I am running the latest build: 1_1_7_3

eclipse.buildId=M20080221-1800
java.version=1_5_0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86

Warning
Sat Dec 13 12:03:01 EST 2008
Trying to connect to (my local host) and got Connection refused: connect

java_net_ConnectException: Connection refused: connect at java_net_PlainSocketImpl_socketConnect(Native Method)

Won’t let me post the rest of the stack trace…
...

Phil

Sorry, That should have been version 1_1_7_39_P20081202

From the stack trace, it looks like the socket connection is being refused.
I tried turning off windows firewall as well as my Comodo firewall.
That had no effect, the socket is still being refused.
I also tried changing the port to something besides 8082, like 8080.
The socket is still being refused.

Looks like i have something on my system that is trying TOO hard to protect me! LOL

Phil

John,
Here is the full stack trace for the error. I still have not figured out why the socket connection is getting refused.

The PDE error log lists two errors and one series of warnings….

First error:

eclipse.buildId=M20080221-1800
java.version=1.5.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86

Error
Sun Dec 14 09:46:11 EST 2008
Problems occurred when invoking code from plug-in: "org.eclipse.debug.core".

java.lang.NullPointerException
at com.buglabs.dragonfly.ui.actions.LaunchVirtualBugAction.removeVBFromBugsView(Unknown Source)
at com.buglabs.dragonfly.ui.actions.LaunchVirtualBugAction.handleDebugEvents(Unknown Source)
at org.eclipse.debug.core.DebugPlugin$EventNotifier.run(DebugPlugin.java:1074)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.debug.core.DebugPlugin$EventNotifier.dispatch(DebugPlugin.java:1108)
at org.eclipse.debug.core.DebugPlugin$EventDispatchJob.run(DebugPlugin.java:360)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Second Error:

eclipse.buildId=M20080221-1800
java.version=1.5.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86

Error
Sun Dec 14 09:46:11 EST 2008
An exception occurred while dispatching debug events.

java.lang.NullPointerException
at com.buglabs.dragonfly.ui.actions.LaunchVirtualBugAction.removeVBFromBugsView(Unknown Source)
at com.buglabs.dragonfly.ui.actions.LaunchVirtualBugAction.handleDebugEvents(Unknown Source)
at org.eclipse.debug.core.DebugPlugin$EventNotifier.run(DebugPlugin.java:1074)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.debug.core.DebugPlugin$EventNotifier.dispatch(DebugPlugin.java:1108)
at org.eclipse.debug.core.DebugPlugin$EventDispatchJob.run(DebugPlugin.java:360)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Continuing series of warnings:

eclipse.buildId=M20080221-1800
java.version=1.5.0_11
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Command-line arguments: -os win32 -ws win32 -arch x86

Warning
Sun Dec 14 09:47:34 EST 2008
Trying to connect to http://127.0.0.1:8082 and got Connection refused: connect

java.net.ConnectException: Connection refused: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(Unknown Source) at java.net.PlainSocketImpl.connectToAddress(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.<init>(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpC…(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at com.buglabs.dragonfly.util.WSHelper.get(Unknown Source) at com.buglabs.dragonfly.util.WSHelper.get(Unknown Source) at com.buglabs.dragonfly.util.BugWSHelper.getPrograms(Unknown Source) at com.buglabs.dragonfly.util.BugListener$TestConnectionJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Any ideas on what i can try?

Thanks
Phil

Hey Phil,

I have to do some more digging to figure out what’s going on. I haven’t seen the errors you’re getting. The warning messages are familiar though.

When you start the Virtual Bug, it starts advertising itself using SLP. SLP is a protocol we use that allows the SDK to discover BUGs on the same network. The (Real or Virtual) BUG will advertise it’s IP address. It has some read-only web services on it that tell the SDK (or any http client) some things about itself, such as the modules attached and the applications running. The virtual bug’s default IP address is localhost:8082.

So, what seems to be happening is the virtual bug is starting, perhaps even advertising itself and getting discovered, and then crashing. The SDK meanwhile keeps polling it at it’s expected IP address (http://localhost:8082). I don’t think it’s a firewall issue or anything. I think that it’s simply, there’s nothing there anymore.

If the Virtual Bug started up normally, you should see a little web page being served from the virtual bug at http://localhost:8082.

Now to figure out why the virtual bug isn’t starting for you… I’ll have to dig deeper. Can you start with a fresh clear console and fresh restart of your machine, then start the virtual bug from the toolbar button? I’d like to see the console output from that.

Thanks.

OK, so did a fresh restart of the machine.
Opened SDK and launched VirtualBug from the toolbar:

Console output is:

I did fire up an old linux box that i have and ran virtual bug. it opened normally and opened the small window showing the base unit and would allow me to attach modules to it. So at least i know what it is supposed to look like.

None of that happens on my main windows machine.

If i write a simple program, like the Hello World app. I can select to debug in virtual bug…all the same console output and i can run the app…set breakpoints, the whole magilla. so it seems that virtual bug is running, at least as far as allowing me to debug an app. It just does not seem to support the UI components.

phil

Hey Phil,

I’m still at a loss as to what’s going on. I see one thing that’s not right to me in your console output—

In my console output I get a few more lines at the end:

I don’t see these servlets being registered in your console output, but I see some servlets being registered earlier. The last line I have listed above registers the root servlet, which is what you get when you go to http://localhost:8082. In your output, I see /module is registered, so try that url in a browser after starting the virtual bug—http://localhost:8082/module If that works, then the virtual bug is running, but is missing some services.

The console in eclipse also becomes the osgi interactive console once the virtual bug is running. In the console, after starting the virtual bug, you should be able to hit the enter key a couple of times and the osgi console prompt that looks like a smiley face should appear. At that prompt, type ‘bundles’ and hit enter. Next type ‘services’ and hit enter. I’d like to see the output of those two commands.

One more question. Did you install the SDK via the eclipse plug-in or was it a full install? Another thing that you might consider trying is an older version of the sdk (like the 1.0.0.8 production release at buglabs.net/sdk). It would be interesting to see if you have the same problems there.

In the meantime, I’ll share this thread with the QA team and some of the other devs here to see if someone can reproduce the problem and maybe get closer to an answer.

Thanks.

any chance something else is already using port 8082? ‘netstat -an|grep 8082’ would show ya.

I tried launching virtual bug from the toolbar and then in console window I tried typing carriage returns
On the second carriage return the console suddenly received:

(:
(: Mon Dec 15 14:32:11 EST 2008 UserAppManager init: false
Mon Dec 15 14:32:11 EST 2008 Registered servlet /program
Mon Dec 15 14:32:11 EST 2008 Registered servlet /configuration
Mon Dec 15 14:32:11 EST 2008 Registered servlet /service
Mon Dec 15 14:32:11 EST 2008 Registered servlet at /service.
Mon Dec 15 14:32:11 EST 2008 Registered resources /

Then the virtual bug window opened normally

Problem Solved!!

It looks like I just need to type a few carriage returns into the console each time I launch virtual bug.

One issue is that you can’t launch Virtual Bug in the new project dialog since it is modal and won’t let you type the carriage returns into the console. I tried launching virtual bug first… entered the carriage returns to complete initialization… then opened the new application dialog. The bugs window showed the running virtual bug and allowed selection of services normally. So that seems to be the only work around needed so far.

Thanks to all for helping to track this down.

Phil

Now that I know the solution, I did a few searches and I did find where this problem was reported in March 2008 by tevslin. His solution was the same…typing into the console to unlock Virtual Bug. This appears to be a bug in the Win32 version of the toolkit.

Phil,

I’m glad you were able to find a work-around. This is really helpful for us as well, because it gives us a better indication of problems people might find down the road and at least the start of being able to fix it. So thanks for the feedback. Hopefully we can get this issue resolved for the next SDK release.