Description Rob Stryker 2015-05-12 15:08:09 EDT

IRemoteLaunchConfigService is a public API class in org.eclipse.remote. 

As a public API class, anyone can call this from any thread. It's not internal, and it's not restricted via any x-friends flags. 

This makes it unsafe for any launch configurations to use this API. 

You can find an example plugin here:  https://github.com/robstryker/jbt-experimental/tree/minimal_example_of_bugs

To replicate the bug, you should import this plugin and run the runtime workbench. Once inside the runtime workbench, you'll see and do a few things:

1) Note that there are 3 launch descriptors in the central menu: Object1, Object2, Object3

2) Create TWO remote connections named "Connection1" and "Connection2".  They should be jsch / ssh style connections

3) in the launchbar UI, select Object1, Run, and "Connection1"

4) Click the launch button

If you look in the example code, inside ServerLaunchBarDelegate, you'll see that I do a few things to force the bug:

1) Create a dummy process
2) Fire a thread which will use the public o.e.remote API to change the active launch config
3) the launch thread will stall for 2 seconds, simulating a remote call
4) When the launch config attempts to get the remote connection to use, it is incorrect. 

Moving this out of public API isn't enough, as launchbar.ui also uses this call.  This can be replicated as follows:

0) Change the delay in ServerLaunchBarDelegate to 5 seconds total
1) Select Object1,  Run, and Connection1
2) Click the 'launch' button in launchbar.ui
3) Quickly change the connection in launchbar.ui to Connection2
4) By the time the launch config reaches the period where it can fetch the target, it is too late. The target has already been changed.