Community
Participate
Working Groups
The following error was reported via the automated error reporting: The user provided the following details for this error report: code: 10,001 plugin: org.eclipse.jdt.ui_3.10.100.v20141027-2358 message: Internal Error fingerprint: 606de395 exception class: org.eclipse.core.internal.resources.ResourceException exception message: Marker id 930065 not found. number of children: 1 org.eclipse.core.internal.resources.ResourceException: Marker id 930065 not found. at org.eclipse.core.internal.resources.Marker.checkInfo(Marker.java:57) at org.eclipse.core.internal.resources.Marker.getType(Marker.java:196) at org.eclipse.jdt.internal.ui.text.correction.CorrectionMarkerResolutionGenerator$CorrectionMarkerResolution.getMarkersForFiles(CorrectionMarkerResolutionGenerator.java:273) at org.eclipse.jdt.internal.ui.text.correction.CorrectionMarkerResolutionGenerator$CorrectionMarkerResolution.findOtherMarkers(CorrectionMarkerResolutionGenerator.java:221) at org.eclipse.ui.internal.views.markers.QuickFixHandler$1.run(QuickFixHandler.java:97) at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:463) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:371) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:500) at org.eclipse.ui.internal.progress.ProgressManager$RunnableWithStatus.run(ProgressManager.java:1380) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager$5.run(ProgressManager.java:1214) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:187) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:145) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4748) at org.eclipse.ui.internal.progress.ProgressManager.runInUI(ProgressManager.java:1211) at org.eclipse.ui.internal.progress.WorkbenchSiteProgressService.runInUI(WorkbenchSiteProgressService.java:396) at org.eclipse.ui.internal.views.markers.QuickFixHandler.execute(QuickFixHandler.java:126) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:295) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) at sun.reflect.GeneratedMethodAccessor50.invoke(null:-1) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:797) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:673) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$6(HandledContributionItem.java:657) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:590) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:638) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:582) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:138) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) --- code: 376 plugin: org.eclipse.core.resources_3.9.100.v20141009-1601 message: Marker id 930065 not found. fingerprint: 00000000 number of children: 0 General Information: reported-by: Ed Willink anonymous-id: 4480ddfc-64ed-45bb-a550-d1669a82122a eclipse-build-id: 4.5.0.I20141029-2000 eclipse-product: org.eclipse.sdk.ide operating system: Windows8 6.3.0 (x86_64) - win32 jre-version: 1.7.0_71-b14 The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.commands_3.6.100.v20141026-0121 2. org.eclipse.core.databinding.observable_1.4.1.v20140910-2107 3. org.eclipse.core.databinding_1.4.100.v20141002-1314 4. org.eclipse.core.resources_3.9.100.v20141009-1601 5. org.eclipse.core.runtime_3.10.0.v20140724-1132 6. org.eclipse.e4.core.commands_0.10.2.v20140424-2344 7. org.eclipse.e4.core.contexts_1.3.100.v20140407-1019 8. org.eclipse.e4.core.di_1.4.0.v20140813-2240 9. org.eclipse.e4.ui.workbench_1.3.0.v20141024-2249 10. org.eclipse.e4.ui.workbench.renderers.swt_0.12.100.v20141021-0910 11. org.eclipse.e4.ui.workbench.swt_0.12.100.v20141020-2115 12. org.eclipse.equinox.app_1.3.200.v20130910-1609 13. org.eclipse.equinox.launcher_1.3.0.v20140415-2008 14. org.eclipse.jdt.ui_3.10.100.v20141027-2358 15. org.eclipse.jdt_3.11.0.v20141029-2000 16. org.eclipse.jface_3.11.0.v20141013-0842 17. org.eclipse.swt_3.104.0.v20141029-1116 18. org.eclipse.ui_3.107.0.v20141010-0853 19. org.eclipse.ui.ide.application_1.0.600.v20141003-0522 20. org.eclipse.ui.ide_3.10.100.v20141024-1629 21. org.eclipse.ui.views_3.7.100.v20141003-0011 Please note that: * Messages, stacktraces, and nested status objects may be shortened. * Bug fields like status, resolution, and whiteboard are sent back to reporters. * The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality. Please visit http://goo.gl/MWFSff for further details. Thank you for your assistance. Your friendly error-reports-inbox.
I've looked up the (to date) top-3 most similar bug groups and listed the closest bug of each group below. This report may or may not be duplicate of those (low or similar scores for all entries may indicate that this hasn't been reported yet): > 1. Bug 448565: [m2e] Marker id 19210 not found. – 0.9 > 2. Bug 451954: [platform] UI freeze of 14s at 23:10:03.249 – 0.4 > 3. Bug 452046: [p2] UI freeze of 1.3s at 16:13:49.946 – 0.4 If this report actually is a duplicate of those, please mark it as such. This information helps me to improve the recommendations further for the next issue. Thank you for your assistance. Your friendly error-reports-inbox.
Happened while closing many projects with a build workspace already in progress. Mising marker id is not surprising. Real problem is a serious lack of build wrt project-open/close synchronization.
(In reply to Ed Willink from comment #2) > Real problem is a serious lack of build wrt project-open/close > synchronization. Ed, can you please elaborate on this please? Thanks!
(In reply to Jayaprakash Arthanareeswaran from comment #3) > (In reply to Ed Willink from comment #2) > > Real problem is a serious lack of build wrt project-open/close > > synchronization. > > Ed, can you please elaborate on this please? Thanks! I'm sure there are many bugs open on this. When you directly open/close multiple projects or indirectly update multiple projects as a consequence of a GIT branch change or even just save many manifests, there is nothing stopping the builder or plugin dependencies updater wasting tons of time starting work too soon and getting it all hideously wrong many times. JDT and many other builders report lots of errors from inconsistent source contexts (this bug). It seems as if each project/manifest change kicks off a new disastrous build. Eventually it usually sorts itself out, but only after a needlessly long time. Not always, so sometimes a clean/rebuld all is needed. Occasionally only a restart will do. We really need something that is aware that many workspace content changes are pending and queues all derived activities until their dependencies are stable. NB this must avoid UI lockouts, so editing a changing project must give a content-frozen editor window, not a go and get a cup of coffee dialog. If there is a problem that non-platform builders are failing to observe platform dependency protocols these must be diagnosed at run-time so that less aware plugin developers can contribute to making Eclipse better rather than worse.
(In reply to Ed Willink from comment #4) > When you directly open/close multiple projects or indirectly update multiple > projects as a consequence of a GIT branch change or even just save many > manifests, there is nothing stopping the builder or plugin dependencies > updater wasting tons of time starting work too soon and getting it all > hideously wrong many times. JDT and many other builders report lots of > errors from inconsistent source contexts (this bug). It seems as if each > project/manifest change kicks off a new disastrous build. Eventually it > usually sorts itself out, but only after a needlessly long time. Not always, > so sometimes a clean/rebuld all is needed. Occasionally only a restart will > do. If things sort themselves out, we don't have a problem, do we? But if it is indeed 'disastrous', then we need to have a closer look at it and fix the issue. Meanwhile, you can try to disable auto build when you know refresh is being done, later on you can enable it back or do a clean build. > stable. NB this must avoid UI lockouts, so editing a changing project must > give a content-frozen editor window, not a go and get a cup of coffee dialog. Interesting thought. Not sure what it takes to come up with something like that, though.
(In reply to Jayaprakash Arthanareeswaran from comment #5) > If things sort themselves out, we don't have a problem, do we? We have two problems. A ten multi-build anarchy takes perhaps sqrt(ten), perhaps ten, perhaps ten-squared times longer than a clean rebuild. The premature builds give numerous errors - missing files/closed projects/inconsistent imports/crazy markers
