Community
Participate
Working Groups
Build Identifier: Helios RC2, DSDP/TM 3.2 RC2 From bug 309899, comment #18: P3: When creating a new terminal-launch and connecting it in a perspective that has no Console View open, the Console View pops up. This is suspicious. Also, if a Console view is present that view sometimes is brought to the top of the stack. I have seen this behavior on Mac OS as well, but it doesn't seem to happen all the time. There must be some additional factor that triggers this bug. Reproducible: Sometimes
I get the following stack trace when it happens: Daemon Thread [Thread-0] (Suspended (breakpoint at line 830 in WorkbenchPage)) WorkbenchPage.bringToTop(IWorkbenchPart) line: 830 ConsoleManager$ShowConsoleViewJob.runInUIThread(IProgressMonitor) line: 307 UIJob$1.run() line: 95 RunnableLock.run() line: 35 UISynchronizer(Synchronizer).runAsyncMessages(boolean) line: 134 Display.runAsyncMessages(boolean) line: 3549 Display.readAndDispatch() line: 3243 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2416 Workbench.runUI() line: 2380 Workbench.access$4(Workbench) line: 2229 Workbench$5.run() line: 504 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 497 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 115 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 369 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 619 Main.basicRun(String[]) line: 574 Main.run(String[]) line: 1406 Main.main(String[]) line: 1382
Hm, on closer inspection this stack trace doesn't help too much, because ShowConsoleViewJob is scheduled asynchronously. The more important question is who is scheduling it (and why). I'm trying another breakpoint at ConsoleManager.showConsoleView(IConsole)...
Since the ShowConsoleViewJob runs asynchronously, this backtrace does not help much. You'll need to set a breakpoint in the constructor of ShowConsoleViewJob to see who requests this job.
Great minds think alike :-) This looks like it could be a race condition related to LocalTerminalProcess.resetStreamsProxy(); I'll look into this tomorrow.
Perhaps it's sufficient when you set the "Allocate Console" checkbox OFF on the Common Tab when creating the default Launch? I did this manually, and could not see a Console pop up.
All right, here's finally a stack trace that shows better how the Local Terminal Connector is involved in this (sure enough, as soon as you really want the bug to happen it stubbornly refused to show itself for quite a while): Daemon Thread [Thread-0] (Suspended (entry into method showConsoleView in ConsoleManager)) ConsoleManager.showConsoleView(IConsole) line: 326 ProcessConsole(AbstractConsole).activate() line: 302 IOConsoleOutputStream.notifyParitioner(String) line: 248 IOConsoleOutputStream.encodedWrite(String) line: 240 IOConsoleOutputStream.write(String) line: 225 ProcessConsole$StreamListener.streamAppended(String, IStreamMonitor) line: 615 ProcessConsole$StreamListener.<init>(ProcessConsole, String, IStreamMonitor, IOConsoleOutputStream) line: 571 ProcessConsole.connect(IStreamMonitor, String, boolean) line: 516 ProcessConsole.connect(IStreamsProxy) line: 485 ConsoleColorProvider.connect(IProcess, IConsole) line: 42 ProcessConsole.<init>(IProcess, IConsoleColorProvider, String) line: 186 ProcessConsoleManager.launchChanged(ILaunch) line: 145 LaunchManager$LaunchNotifier.run() line: 452 SafeRunner.run(ISafeRunnable) line: 42 LaunchManager$LaunchNotifier.notify(ILaunch, int) line: 433 LaunchManager.fireUpdate(ILaunch, int) line: 995 Launch.fireChanged() line: 388 Launch.addProcess(IProcess) line: 351 LocalTerminalProcess(RuntimeProcess).<init>(ILaunch, Process, String, Map) line: 125 LocalTerminalProcess.<init>(ILaunch, Process, String, Map) line: 82 LocalTerminalProcessFactory.newProcess(ILaunch, Process, String, Map) line: 38 DebugPlugin.newProcess(ILaunch, Process, String, Map) line: 722 LocalTerminalLaunchDelegate.launch(ILaunchConfiguration, String, ILaunch, IProgressMonitor) line: 199 LaunchConfiguration.launch(String, IProgressMonitor, boolean, boolean) line: 853 LaunchConfiguration.launch(String, IProgressMonitor, boolean) line: 702 LaunchConfiguration.launch(String, IProgressMonitor) line: 695 LocalTerminalConnector.connect(ITerminalControl) line: 212 TerminalConnector.connect(ITerminalControl) line: 159 VT100TerminalControl.connectTerminal() line: 318 TerminalView.onTerminalConnect() line: 292 TerminalView.newConnection(String) line: 331 TerminalView.onTerminalSettings() line: 324 TerminalActionSettings.run() line: 37 TerminalActionSettings(Action).runWithEvent(Event) line: 498 ActionContributionItem.handleWidgetSelection(Event, boolean) line: 584 ActionContributionItem.access$2(ActionContributionItem, Event, boolean) line: 501 ActionContributionItem$6.handleEvent(Event) line: 452 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 3725 ToolItem(Widget).sendEvent(Event) line: 1333 ToolItem(Widget).sendEvent(int, Event, boolean) line: 1356 ToolItem(Widget).sendEvent(int, Event) line: 1341 ToolItem(Widget).notifyListeners(int, Event) line: 1155 Display.runDeferredEvents() line: 3585 Display.readAndDispatch() line: 3241 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2416 Workbench.runUI() line: 2380 Workbench.access$4(Workbench) line: 2229 Workbench$5.run() line: 504 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 497 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 115 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 110 EclipseAppLauncher.start(Object) line: 79 EclipseStarter.run(Object) line: 369 EclipseStarter.run(String[], Runnable) line: 179 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 619 Main.basicRun(String[]) line: 574 Main.run(String[]) line: 1406 Main.main(String[]) line: 1382
(In reply to comment #5) > Perhaps it's sufficient when you set the "Allocate Console" checkbox OFF on the > Common Tab when creating the default Launch? I did this manually, and could not > see a Console pop up. I suspect that that was more attributable to the fact that we're probably dealing with a race condition here, and you just got lucky. The "Allocate Console" option (as well as another non-UI option that also controls aspects of how local launches interact with a console) actually needs to be turned ON, and LocalTerminalConnector.java, line 206/207 actually contains code that programmatically sets those options. I'll double-check this code as part of my investigation.
Created attachment 170320 [details] Patch to avoid Console allocation when IStreamMonitor already contains data during RuntimeProcess initialization ProcessConsoleManager.launchChanged(ILaunch) will cause a Console to appear if the IStreamMonitor of the process already contains data at that point. The patch cuts the problematic code path at org.eclipse.debug.ui.console.ConsoleColorProvider.connect(IProcess, IConsole) (line 41). I also updated the javadoc documentation to explain this fix. Unless there are other code paths that have a similar side effect the patch should fix the issue. I tried reproducing the problem for quite some time after adding the patch but it appears to be fixed.
Patch applied, tested, released > I20100528. Thanks!
