Community
Participate
Working Groups
WorkbenchErrorHandler is not correctly handling critical errors that occur while the critical error dialog is open. Whenever the error handler attempts to handle a critical error, it spins up a modal event loop. However, if the modal event loop is already running and another error occurs, it spins up a second (or third, etc.) event loop. This can lead to stack overflow, UI freezes, and other nastiness. May be related to the fix for bug 501681. Here is a recursive error handler chain reported by a user (this is the repeating section in the middle of a very long stack trace): at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4533) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4151) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.showStatusAdapter(WorkbenchErrorHandler.java:86) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.lambda$0(WorkbenchErrorHandler.java:51) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler$$Lambda$126/1711268657.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4533) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4151) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.showStatusAdapter(WorkbenchErrorHandler.java:86) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler.lambda$0(WorkbenchErrorHandler.java:51) at org.eclipse.ui.statushandlers.WorkbenchErrorHandler$$Lambda$126/1711268657.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:182) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4533) I've been able to reproduce a very similar stack trace using the following snippet: public class TriggerRecursiveErrorHandling extends AbstractHandler { Job errorJob = Job.create("Triggering a lot of OOMEs", monitor -> { for (int idx = 0; idx < 1000; idx++) { UIJob errorJob = new UIJob("Triggering a lot of OOMEs") { public IStatus runInUIThread(IProgressMonitor monitor) { throw new OutOfMemoryError(); } }; errorJob.schedule(); } }); @Override public Object execute(ExecutionEvent event) throws ExecutionException { errorJob.cancel(); errorJob.schedule(); return null; } } And this XML: <command name="Trigger recursive error handling" description="Trigger recursive error handling" defaultHandler="org.eclipse.jdt.internal.ui.commands.TriggerRecursiveErrorHandling" categoryId="org.eclipse.ui.category.project" id="org.eclipse.jdt.ui.triggererrors"> </command> Possible fixes: - Deprecate the StatusManager.BLOCK flag and change it into a no-op. - Keep the flag but remove all uses of it within the Eclipse platform (especially the one within WorkbenchErrorHandler.handle).
Another possible fix would be to stop handling errors via dialogs if the error handling is not finished yet?
> Another possible fix would be to stop handling errors via dialogs > if the error handling is not finished yet? That's fine, too. However, if we did this we wouldn't be able to honor the API promise of the BLOCK flag to block the calling thread until the error has been "dealt with". Fortunately, the exact meaning of "dealt with" is poorly specified, and we could define it to mean "received by the error handler". However, that would mean that BLOCK would effectively become a no-op, so if we went this route we may as well deprecate it.
New Gerrit change created: https://git.eclipse.org/r/86408
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
