Bugzilla – Full Text Bug Listing
| Summary: | Java Application debug launches are only 99% complete | ||
|---|---|---|---|
| Product: | [Modeling] Acceleo | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Project Inbox <acceleo-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | laurent.goubet, stephane.begaudeau |
| Version: | 3.0.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Ed Willink
Problem observed on RC1, but also long ago too. Problem also arrises if yoiu do interactive Java editing while debugging. After a bit Eclipse can lock up with a wait cursor. (RC3) Problem can arise in a Run as well. If a query invokes a Java method that loops forever, the UI is locked out and Eclipse must be terminated. Normal JDT launches allow a looping program to be killed via the Debug perspective. (In reply to comment #2) > If a query invokes a Java method that loops forever, the UI is locked out and > Eclipse must be terminated. which doesn't terminate the looping Acceleo launch, so you are left with a mysteriously dead machine in which to try to repair a broken workspace. 3.1 Raising to major since if for instance the Sample Ecore Editor is used and saved while a debug session is at a breakpoint, Eclipse is totally locked up. Workaround kill the java VM for the debug session. (In reply to comment #4) > Workaround kill the java VM for the debug session. Better to just code as in Bug 380077. The ordering of lines in AcceleoDebugTarget.terminate is suspect: fireTerminateEvent(); debugger.terminate(); what if fireTerminateEvent throws an Exception? (In reply to comment #5) > (In reply to comment #4) > > Workaround kill the java VM for the debug session. > > Better to just code as in Bug 380077. > > The ordering of lines in AcceleoDebugTarget.terminate is suspect: > > fireTerminateEvent(); > debugger.terminate(); > > what if fireTerminateEvent throws an Exception? With the regular behavior, an exception should not occur but the order is indeed troubling. I've changed the order of those operations. The original problem of this bug lies in the fact that all Acceleo generations are "workspace modifying operations" and the platform will rightfully consider those operations as atomic so any other workspace modifying operation will be locked by an Acceleo operation. This was the intended behavior since *we are modifying the workspace* and using the state of the workspace during the generation. We want to prevent anyone from modifying the generators, the models or even the generated files during the generation. The ability to cancel a launch provided in RC1 makes thinfgs much better, but there is still a lack of control because the launch is model and waiting for the launched job. It seems to be that the problems would go away if the launch was just a fire-and-forget so that there was no residual UI activity. I'm not sure if this is the same bug or not. An Acceleo launch can lock up with a synchonization deadlock between: Thread [Refresh Packages] (Suspended) AcceleoWorkspaceUtil.dispose() line: 475 AcceleoCommonPlugin.stop(BundleContext) line: 271 BundleContextImpl$2.run() line: 771 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method] BundleContextImpl.stop() line: 764 BundleHost.stopWorker(int) line: 510 BundleHost(AbstractBundle).suspend(boolean) line: 566 Framework.suspendBundle(AbstractBundle, boolean) line: 1206 PackageAdminImpl.suspendBundle(AbstractBundle) line: 326 PackageAdminImpl.processDelta(BundleDelta[], boolean, State) line: 467 PackageAdminImpl.doResolveBundles(Bundle[], boolean, FrameworkListener[]) line: 251 PackageAdminImpl$1.run() line: 174 Thread.run() line: 722 and Thread [Worker-44] (Suspended) Object.wait(long) line: not available [native method] AcceleoWorkspaceUtil.refreshPackages(Bundle[]) line: 810 AcceleoWorkspaceUtil.installBundle(IPluginModelBase) line: 934 AcceleoWorkspaceUtil.checkRequireBundleDependencies(IPluginModelBase) line: 879 AcceleoWorkspaceUtil.installBundle(IPluginModelBase) line: 928 AcceleoWorkspaceUtil.checkRequireBundleDependencies(IPluginModelBase) line: 879 AcceleoWorkspaceUtil.installBundle(IPluginModelBase) line: 928 AcceleoWorkspaceUtil.refreshContributions() line: 722 AcceleoWorkspaceUtil.getClass(String, boolean) line: 508 AcceleoLaunchOperation.run(IProgressMonitor) line: 102 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2344 Workspace.run(IWorkspaceRunnable, IProgressMonitor) line: 2326 AcceleoPluginLaunchingStrategy.launch(IProject, String, String, File, List<String>, IProgressMonitor) line: 239 AcceleoPluginLaunchingStrategy.launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor) line: 141 AcceleoLaunchDelegate.launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor) line: 51 LaunchConfiguration.launch(String, IProgressMonitor, boolean, boolean) line: 855 LaunchConfiguration.launch(String, IProgressMonitor, boolean) line: 704 DebugUIPlugin.buildAndLaunch(ILaunchConfiguration, String, IProgressMonitor) line: 1047 DebugUIPlugin$8.run(IProgressMonitor) line: 1251 Worker.run() line: 54 Ed,
This dead lock does not seem like a good candidate for the "never ending" debug launches. However, it does show that we do not cancel our builds when closing the platform ("there should never be jobs running when stopping..." and the like). Seems like :
1 - we need some synchronization/locking to avoid the possibility of a "dispose" call when anything else is running (even if it should never happen, this remains a dead lock possibility)
2 - We need to make sure that our build jobs are interrupted when the workbench closes.
The debugger is no longer available since mars |