Community
Participate
Working Groups
Created attachment 117868 [details] Proposed patch Build ID: M20080911-1700 Steps To Reproduce: The following steps demonstrate the problem by using the JDT, but in fact the bug is in the Platform: 1. Set a breakpoint at the monitor.done() line right near the end of JavaLaunchDelegate.launch(). 2. Debug Eclipse 3. In the child instance of Eclipse, turn off auto-build 4. Make a new Java project "J", and add a class "J" with a main function. 5. Run > Run As > Java Application. 6. After you hit the breakpoint, step over the monitor.done() call. 7. Look at the status bar in the child instance of Eclipse. Actual result: You will see this: "Launching J: (91%)". Expected result: If you look at the callstack (or step through the code), you will see that every progress monitor all the way up the callstack has actually completed all of its work, so the Progress view should show the job being at 100%. Fix: There are several places in LaunchConfigurationDelegate that are not doing the right thing with the passed-in IProgressMonitor (which, in this workflow, is a SubProgressMonitor that was created by LaunchConfiguration.launch()). Several functions do not call beginTask() / done() on the monitor, which means that the parent monitor's progress will not be advanced. In addition, one function mis-uses the monitor in a different way, accidentally calling beginTask() / done() on it more than once (the function buildProjects). See attached patch for a proposed fix. When you apply this patch and then follow the above repro steps, you will see "Launching J: (99%)". I would have expected 100%, but 99% is close enough for me. Perhaps there is another error case I missed. The only potential problem with my proposed patch is that I am passing the empty string in all my added calls to IProgressMonitor.beginTask() -- that is, I am calling monitor.beginTask("", 1) in several places. I don't see this as a big problem, because (at least in this code path) all of these places are being called with a SubProgressMonitor, and so the task name is going to be ignored anyway (although of course I realize it is uncool to assume what sort of monitor you are going to be called with); plus, there are other places in Eclipse that do the same thing, such as Project.internalBuild(). Plus maybe I'm being a teeny bit lazy.
Applied patch. Added some null checks for monitors.
Removing iplog+ from bug - this indicates an IP contribution in a comment rather than a patch. http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log