Key in the cognition - Making remote debugging easier to use

Feb. 9th, 2007

12:14 am - Making remote debugging easier to use

Previous Entry Add to Memories Share Next Entry

Shortly after joining VMware, I took on the challenge of making it easier for software developers to debug code running in a production environment where they don't have all the tools normally available to them during development. Traditionally, the only way to accomplish this has been through the use of remote debugging. However, while remote debugging can be extremely useful in certain situations, getting it to work is sufficiently cumbersome that it has remained the domain of the truly desperate. There are two parts to the process: running the code in debug mode on the production machine and then attaching a debugger on the development machine to the code running on the production machine. I realized that I could vastly improve the user experience if I could automate all this drudgery and present it to developers as a one-click action. But I knew that doing this would require a sequence of nontrivial actions:


  1. after building the code on the development machine, make the executable available on the production environment;
  2. execute the application inside the production environment so that it is prepared to accept a connection from a remote debugger;
  3. attach a debugger on the development machine to the application instance running in the production environment.

It didn't take long to realize that the first two steps would be fairly straightforward if the production environment was a virtual machine because then I could use Shared Folders to accomplish the first step and use our new automation API to accomplish the second. Fortunately, it is now possible to turn physical machines into virtual ones with minimal fuss.

Since nobody else had ever attempted to do something like this before, I decided to keep it simple at first to minimize the risk of failure. That meant choosing my battles carefully when tackling the third step. For the initial release, my target was limited to pure Java standalone applications developed using the Eclipse IDE, although it was to work on any combination of Windows and Linux as host and guest platforms.

I began by talking to a few Workstation customers who also use Eclipse for Java development so I could get a feel for their workflow and pain points. Then I sketched out the proposed workflow model for virtualization-assisted remote debugging and ran it by them along with rough mockups of my UI ideas. Based upon their feedback, I designed the feature as an Eclipse plugin that adds a new type of Launch Configuration to the stock set. The UI for this new launch config reuses most of the tabs already familiar to Eclipse users from running Java apps locally and adds a new one with a few virtualization options, of which only one requires the user to make a choice: in which VM should the code be executed? Once a launch configuration has been created and a VM selected, as with any other launch config, it can be activated in future simply by clicking on the Debug button in the Eclipse toolbar.

When activated, the plugin powers on the selected VM if necessary, shares the project folder containing the bytecode with the guest OS, finds an available dynamic port to use for remote debugging, looks for a JVM on the guest in the most likely locations until it find one, executes the application in debug mode and finally attaches the Eclipse visual debugger to the previously determined port on the VM. When the application is terminated, the plugin removes the shared folder so as not to leave a mess. For additional flexibility, developers also have the ability to do a few other potentially useful things:
Knowing that some Java developers would be using more complex runtime environments like application servers, I opportunistically threw them a bone as well. If they can get their application to run in debug mode and wait for a remote debugger to attach to it then I offer to them yet another type of Launch Configuration that greatly improves the user experience of attaching the Eclipse visual debugger to an arbitrary Java application running inside a VM. This one presents them with a nice list of instances of a particular Java application running on a particular VM so that they can pick the one they wish to debug instead of having to manually specify IP addresses and port numbers - the sort of details that made remote debugging a pain to use.

Keeping in mind that attention to detail means a lot when it comes to user experience, I added a few little niceties where possible. For instance, instead of always having to browse for the location of a VM, you can nearly always select it from a list of currently running and recently used VMs. And because most people won't care about sharing additional folders during debugging, I tucked the UI for that into a disclosure triangle. In keeping with the Eclipse tradition of always using a cancellable progress dialog for long-running operations, every step of the automated remote debugging process is accompanied by one of those. Finally, our Tech Pubs folk broke with their tradition of using PDF documentation to provide simple HTML user assistance that I integrated with the Eclipse Help system.

Anyway, that's enough from me! I want to hear what you have to say about this so grab a copy of the freshly minted Workstation 6.0 beta3 that includes the Eclipse plugin I made and take it for a spin.

Update: a least one developer is pretty excited about this.

Tags:
Current Mood: hopefulhopeful
Current Music: Hey Jude - The Beatles

Comments:

[User Picture]
From:kinthelt
Date:February 10th, 2007 04:21 pm (UTC)
(Link)
Grooviness. There's a _VERY_ good chance I'll adopt this. :)

I heard a rumour that a Linux version of VMware Converter is going to be released real soon now.
(Reply) (Thread)
From:7wrc
Date:May 2nd, 2007 04:21 am (UTC)
(Link)
Is it any current info in this issue?
(Reply) (Parent) (Thread)
[User Picture]
From:quikchange
Date:May 6th, 2007 05:29 am (UTC)
(Link)
Which issue? There's still no Converter for Linux.
(Reply) (Parent) (Thread)
From:laurenice
Date:May 6th, 2007 02:01 am (UTC)
(Link)
Thanks Tony for the useful information.
(Reply) (Thread)
[User Picture]
From:bitpuddle
Date:May 12th, 2007 02:01 am (UTC)
(Link)
This Eclipse integration is a really interesting feature -- can't wait to play with it.

Any idea if this will ever make its way into the MacOS version (Fusion)?
(Reply) (Thread)
[User Picture]
From:quikchange
Date:May 12th, 2007 08:57 am (UTC)
(Link)
If we decide to port Workstation to the Mac, it will include the Eclipse integration. Whether or not that happens will be influenced by the success that Fusion enjoys.
(Reply) (Parent) (Thread)
[User Picture]
From:bitpuddle
Date:May 12th, 2007 01:16 pm (UTC)
(Link)
Cool beans. Thanks for the info.
(Reply) (Parent) (Thread)
From:bvenkata
Date:September 14th, 2007 12:59 am (UTC)

Nice tool - help with an issue..?

(Link)
Tony-

Just got the 6.0 Workstation - it's awesome ! added the Eclipse debugger and when launching it from the host OS (XP Pro) I get this:

"Launching: Sharing folders required to debug project"

my guest is a Red Hat Linux 4. Suggestions ? I tried VMWare website, KB and sites that talk abt the debugger - can't find any help :(


TIA

/bala
(Reply) (Thread)
[User Picture]
From:quikchange
Date:September 14th, 2007 07:47 am (UTC)

Re: Nice tool - help with an issue..?

(Link)
Do you have the VMware Tools software installed and configured in your Redhat guest?
If so, see whether you can manually share a folder with the guest using Workstation and then access it from within the guest.
(Reply) (Parent) (Thread)
From:bvenkata
Date:September 14th, 2007 04:54 pm (UTC)

Re: Nice tool - help with an issue..?

(Link)
Yep. Shared. In fact I think Eclipse added a shared folder and I was able to view it in my guest RHEL. Noticed something odd in there though. The folder it shared was "D:\views\bvenkata_snap_main\INM\Apache\htdocs" but the name it gave for the share was ".project-htdocs". Dunno if that's the default behavior ? But in my guest I see a /mnt/hgfs/.project-htdocs directory. Btw, I am not running any firewall in my guest RHEL (disabled it).


TIA

/bala
(Reply) (Parent) (Thread)
[User Picture]
From:quikchange
Date:September 14th, 2007 06:14 pm (UTC)

Re: Nice tool - help with an issue..?

(Link)
"Sharing folders required to debug project" is not one of the error messages I wrote into the code. Can you please provide the exact text of the error so I can search for it?
(Reply) (Parent) (Thread)
From:bvenkata
Date:September 14th, 2007 06:54 pm (UTC)

Re: Nice tool - help with an issue..?

(Link)
Tony-

Thanks for looking. I just sent an email to your gmail id which I saw on your webpage.


/bala
(Reply) (Parent) (Thread)
From:mcico
Date:June 2nd, 2008 07:14 pm (UTC)

problem with remote attach?

(Link)
I have been trying to do a remote attach, but I keep getting an error like the one below. I'm setting the address explicitly for JPDA when I start the process in the guest OS...


!MESSAGE Only the JPDA socket transport may be used for remote debugging
!STACK 0
java.lang.NumberFormatException: For input string: "localhost:5003"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at com.vmware.bfg.JavaProcessData.getPortNumber(JavaProcessData.java:62)
at com.vmware.bfg.AttachConfigDelegate.getPortNumFromUser(AttachConfigDelegate.java:144)
at com.vmware.bfg.AttachConfigDelegate.launch(AttachConfigDelegate.java:83)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:639)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:565)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:558)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:758)
at org.eclipse.debug.internal.ui.DebugUIPlugin$6.run(DebugUIPlugin.java:944)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
(Reply) (Thread)
[User Picture]
From:quikchange
Date:June 2nd, 2008 08:24 pm (UTC)

Re: problem with remote attach?

(Link)
Go to http://java.sun.com/j2se/1.5.0/docs/guide/jpda/conninv.html#Transports and scroll down to the 3rd paragraph of the Socket Transport subsection. It says:
In contexts where a client is attaching to a server, socket transport addresses have the format ":" where is the host name and is the socket port number at which it attaches or listens. In contexts where a server is waiting for a client to attach, the address consists of the port number alone (the host name is implicit).

If you omit the localhost part from your command line when starting the process, I think it will solve the problem.
(Reply) (Parent) (Thread)