Community
Participate
Working Groups
Hello committers, we received a new error report for Eclipse 4.5.0.I20140918-0330. General Information: anonymous-id: cb778dfd-6956-4ebb-9e2f-81dcdcb9cf51 eclipse-build-id: 4.5.0.I20140918-0330 eclipse-product: org.eclipse.platform.ide operating system: Linux 3.13.0 (x86_64) - gtk java-runtime-version: 1.7.0_67-b01 The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.jobs_3.6.100.v20140821-1523 2. org.eclipse.xtext.ui_2.7.2.v201409160908 3. org.eclipse.xtext_2.7.2.v201409160908 4. org.eclipse.xtext.util_2.7.2.v201409160908 Error Status: code: 2 plugin: org.eclipse.core.jobs_3.6.100.v20140821-1523 message: HIDDEN fingerprint: 55e8b424 exception class: java.lang.NullPointerException exception message: HIDDEN number of children: 0 java.lang.NullPointerException: HIDDEN at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport.getResourceDescriptionManager(DirtyStateEditorSupport.java:496) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport.announceDirtyState(DirtyStateEditorSupport.java:466) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.postParse(XtextDocumentReconcileStrategy.java:160) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.doReconcile(XtextDocumentReconcileStrategy.java:146) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:65) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.doRun(XtextReconciler.java:401) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.access$3(XtextReconciler.java:386) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:327) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:1) at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36) at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:418) at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:131) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:324) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Messages, stacktraces, and nested status objects may be shortened. Please visit http://dev.eclipse.org/recommenders/committers/confess/0.5/reports/54381bf0e4b08c254462347b for the complete error log. Some general information and guidelines about how to use this bug report: 1. Feel free to move this bug to your own product and components. Please note that this bug is only accessible to Eclipse committers. If you move this bug please make sure that it's still in the "Security Advisor" group. 2. The bug contents of the fields status, resolution, keywords, and whitelist are presented to reporters. If you needs more information, please set the keyword "needinfo". This will trigger a specialized dialog asking the user to provide further details. 3. Use the following resolutions for the following situations: * CLOSED / FIXED: This bug has been fixed. Please provide additional information in the whiteboard field. * CLOSED / WORKSFORME: Use this resolution if you can't reproduce this issue and request further information. Please use the whiteboard text to specify more details what a user should provide and how. * CLOSED / INVALID: Use this resolution if the reported problem is a 'user-configuration' problem. Please consider giving hints how to fix these issues in the whiteboard field. * CLOSED / NOT ECLIPSE: Use this if the problem is caused by another plugin not developed at Eclipse.org * CLOSED / MOVED: If this bug has been moved else where. Please provide more information (e.g. a link) in the whiteboard field. 4. Please remember that only committers can view and comment on this bug. You may, however, manually add the reporting user to the bug's cc list. But keep in mind that the report may contains sensitive information. 5. If you are missing a feature, please file a enhancement request here: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Recommenders.Incubator&component=Stacktraces Thank you for your assistance. Your friendly error-reports-inbox. -- * Note: The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality.
To date this log entry was reported 10 times. Your friendly error reports bot.
Problem persists in 2.8: 1. org.eclipse.core.jobs_3.6.100.v20140821-1523 2. org.eclipse.xtext.ui_2.8.0.v201409300608 3. org.eclipse.xtext_2.8.0.v201409300608 4. org.eclipse.xtext.util_2.8.0.v201409300608
The stackframes are out of sync with 2.8 / 2.7.3. Marcel, could you provide an up-to-date stacktrace and steps to reproduce?
The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.jobs_3.6.100.v20140821-1523 2. org.eclipse.xtext.ui_2.8.0.v201409300608 3. org.eclipse.xtext_2.8.0.v201409300608 4. org.eclipse.xtext.util_2.8.0.v201409300608 Error Status: code: 2 plugin: org.eclipse.core.jobs_3.6.100.v20140821-1523 message: An internal error occurred during: "XtextReconcilerJob". fingerprint: d8899695 exception class: java.lang.NullPointerException exception message: - number of children: 0 java.lang.NullPointerException: null at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport.getResourceDescriptionManager(DirtyStateEditorSupport.java:503) at org.eclipse.xtext.ui.editor.DirtyStateEditorSupport.announceDirtyState(DirtyStateEditorSupport.java:473) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.postParse(XtextDocumentReconcileStrategy.java:167) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.doReconcile(XtextDocumentReconcileStrategy.java:151) at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:70) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.doRun(XtextReconciler.java:412) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.access$3(XtextReconciler.java:396) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:337) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:1) at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:36) at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:403) at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:144) at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:334) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
The line numbers are still out of sync. Any chance for you to grab a more recent build, e.g. from http://download.eclipse.org/modeling/tmf/xtext/updates/composite/latest/
Sorry, I'm not the reporter. Adding needinfo keyword + whiteboard message to let the next reporter know (see [1] for an example how he/she will get notified). For user reports that use your latest versions, you may add the automated error reporting to your Mars Milestones DSL package. [1] http://youtu.be/bODLj6q7jxo?t=1m58s
See Bug 452162 where we are trying to find a workaround for the Xtext anomally.
(In reply to Ed Willink from comment #7) > See Bug 452162 where we are trying to find a workaround for the Xtext > anomally. The problem seems to be fixed in Xtext 2.7.3 and involves a new API in 2.7.0 that has already been deprecated for 2.8. The problem is that with minimal Xtext dependencies, the OCLinEcore editor that can be a text editor for *.oclinecore files, or for *.ecore files only has an org.eclipse.xtext.extension_resourceServiceProvider registration for *.oclinecore. When the full Xtext SDK is installed a *.ecore registration is provided by org.eclipse.xtext.ui.ecore. When a *.ecore registration is present the NPE does not happen. So the problem is that Xtext is broken for some OCL/Xtext version combinations. Since this is fixed in 2.7.3 and deprecated in 2.8 there is presumably not a great deal that Xtext can do to help. OCL can do an early SR2 that avoids the bad 2.7.2 behaviour by adding a org.eclipse.xtext.ui.ecore dependency. OCL could of course adds its own *.ecore registration and 'solve' the problem without pulling in unnecessary plugins but then no doubt this would create a battle whenever OCL and a full Xtext SDK are both installed. What is the purpose of what seems to me to be a duplication of a standard EMF registration? Should OCL be providing a definition of it? Has the 2.7.2 problem gone away for ever or is it just fortunate that the OCL editors work while using an unexpected Xtext *.ecore registration?
(In reply to Ed Willink from comment #8) > What is the purpose of what seems to me to be a duplication of a standard > EMF registration? What exactly is a duplicate of a standard EMF registration? The resource service provider? Why? > Should OCL be providing a definition of it? I guess you are talking of resource service providers? No, it should not. There can only be one and that should be the one coming from the language declarator. I.e. for *.ecore it should be provided by EMF. Currently it's still provided by Xtext, but this is more to be seen as a service for the EMF project :-) > Has the 2.7.2 > problem gone away for ever or is it just fortunate that the OCL editors work > while using an unexpected Xtext *.ecore registration? The fix (see bug #446319) was done such that you can open any kind of text file with any Xtext editor. But since in a shared context (i.e. builder and dirty state manager) there can only be one implementation per language (read file extension) only those implementations are allowed to contribute there. That's why 'wrong' editors don't push events to the dirty state. An editor is considered 'wrong' if the resource service provider registry returns a different language name for the given file extension. I.e. OCL editor is 'wrong' for *.ecore files. *** This bug has been marked as a duplicate of bug 446319 ***
(In reply to Sven Efftinge from comment #9) bug #446319 makes most things clear and indeed suggests that org.eclipse.xtext.extension_resourceServiceProvider should not be used for a running editor. > (In reply to Ed Willink from comment #8) > > What is the purpose of what seems to me to be a duplication of a standard > > EMF registration? > > What exactly is a duplicate of a standard EMF registration? The resource > service provider? Why? org.eclipse.emf.ecore.extension_parser is the long established mapping from extension to Resource.Fatory and so Resource. org.eclipse.ui.editors is the long established mapping from extension to editor. I'm not clear why org.eclipse.xtext.extension_resourceServiceProvider is needed. Surely some method such as XtextEditor.getResourceServiceProvider() should be able to provide a sensible response based on the overrideable injection in MyEditorUiModule.java?
ResourceServiceProvider is the mapping from extension to ResourceDescriptionManager (and many other Xtext-specific implementations).
I've never had any need to use a ResourceDescriptionManager. My question is why this is not deducible via the editor?
Because it would only give you the implementation of the editor's guice injector, which is the 'wrong' one.
