Closed eclipse-ocl-bot closed 2 hours ago
By EPP Error Reports on Oct 31, 2014 07:35
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 449180](https://bugs.eclipse.org/bugs/show_bug.cgi?id=449180): [ltk] The resource tree is locked for modifications. – 0,9 2. [Bug 446699](https://bugs.eclipse.org/bugs/show_bug.cgi?id=446699): [ltk] The resource tree is locked for modifications. (err_grp: e40b0639) – 0,9 3. [Bug 447758](https://bugs.eclipse.org/bugs/show_bug.cgi?id=447758): [platform] HIDDEN – 0,8
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.
By Ed Willink on Nov 03, 2014 07:20
org.eclipse.qvtd.xtext.qvtimperative has not yet been released.
By Marcel Bruch on Nov 03, 2014 08:38
Moved the comment into the whiteboard to let users give a chance to see this. Making this bug accessible for non-committers since it does not contain any sensitive data.
By EPP Error Reports on Nov 06, 2014 10:46
Bug 450364 has been marked as a duplicate of this bug.
By EPP Error Reports on Nov 27, 2014 10:46
To date this log entry was reported 10 times.
Your friendly error reports bot.
By Ed Willink on Dec 01, 2014 03:26
Bug 453669 has been marked as a duplicate of this bug.
By Ed Willink on Dec 01, 2014 03:30
I think this occurs when trying to save the Abstract Syntax within an Xtext 'OCL' editor; EMF has an API that is more restrictive than might at first appear.
Hopefully this is now fixed.
By Ed Willink on Mar 18, 2015 06:29
(In reply to Ed Willink from comment #7)
I think this occurs when trying to save the Abstract Syntax within an Xtext 'OCL' editor; EMF has an API that is more restrictive than might at first appear.
Hopefully this is now fixed.
AERI shows 23 occurrences from Nov-2014 to Jan-2015, but none in the last 8 weeks.
Looks like it was fixed in M4 or M5 and user has upgraded.
By Ed Willink on Mar 19, 2015 08:38
(In reply to Ed Willink from comment #8)
Looks like it was fixed in M4 or M5 and user has upgraded.
No. Found it.
The problem occurs on the first save of a *.qvtr file, which uses the base XTextDocumentProvider which fails to ensure a non-null encoding when the source file description is being obtained.
The stack trace below identifies the point at which the null encoding is assigned rather than used.
Thread [main] (Suspended) \
owns: WorkspaceModifyDelegatingOperation (id=613) \
URIConverter$ReadableInputStream.
By Ed Willink on Mar 20, 2015 08:49
(In reply to Ed Willink from comment #9)
The problem occurs on the first save of a *.qvtr file9
No. *.qvtc etc too.
(In reply to Ed Willink from comment #9)
The stack trace below identifies the point at which the null encoding is assigned rather than used.
Stepping through the corresponding code when saving a *.xtext file reveals that Xtext does not / no longer registers a contenttype, so no attempt to analyze the XML is made and no null encoding or NPE occurs.
Simple fix: eliminate all the CS contenttype registrations.
Better fix: use a derived RootXMLContentHandlerImpl in the contenttype registration that ensures that no NPE occurs.
By Ed Willink on Mar 20, 2015 10:22
(In reply to Ed Willink from comment #10)
Better fix: use a derived RootXMLContentHandlerImpl in the contenttype registration that ensures that no NPE occurs.
Actually just need a derived Describer to ensure that the null encoding is an IOException that the platform ignores rather than an NPE.
public class BaseContentHandlerDescriber extends ContentHandlerImpl.Describer\ {\ protected static class BaseReadableInputStream extends URIConverter.ReadableInputStream\ {\ protected BaseReadableInputStream(Reader xmlReader) throws IOException {\ super(xmlReader);\ if (encoding == null) {\ throw new IOException("Not an XML file");\ }\ }
@Override\
public String getEncoding() {\
String encoding = super.getEncoding();\
return encoding != null ? encoding : null;\
}\
}
@Override\
public int describe(Reader reader, IContentDescription description) throws IOException\
{\
return describe(new BaseReadableInputStream(reader), description);\
}\
}
But the problem only occurs if the genmodel has a non-null contentTypeIdentifier.
Should the above be in EMF? but should EMF need to guard against non-XML content.
Perhaps better an Xtext fix, since Xtext is where the problem arises.
By Ed Willink on Mar 20, 2015 10:54
(In reply to Ed Willink from comment #11)
Perhaps better an Xtext fix, since Xtext is where the problem arises.
An XText fix is only possible by overriding the whole of FileDocumentProvider.doSaveDocument since getCharsetForNewFile where an exception needs catching is private. See Bug 461191 for a suggested platform tolerance; would still give an irritating log message.
Today and for backward compatibility only the BaseContentHandlerDescriber is an option.
By Ed Willink on Mar 20, 2015 14:08
(In reply to Ed Willink from comment #10)
(In reply to Ed Willink from comment #9)
The problem occurs on the first save of a *.qvtr file9
No. *.qvtc etc too.
(In reply to Ed Willink from comment #9)
The stack trace below identifies the point at which the null encoding is assigned rather than used.
Stepping through the corresponding code when saving a *.xtext file reveals that Xtext does not / no longer registers a contenttype, so no attempt to analyze the XML is made and no null encoding or NPE occurs.
No. The true problem is a confusion between the text extension .X and the CS extension .Xcs, as a consequence of which both are handled by the XML content type analysis.
Once the spurious registrations are removed, so is the problem.
OCL: commit b4006ce57d10d95b3062b2b90c90db686780cfd6\ QVTd: commit 4e5a45c1c53633da76b1333736f371265215f221
pushed to master for M6.
(This was a quite horrible error; it will be interesting to see if other problems vanish. But it's odd that it requires an AERI report to discover that saves are failing.)
| --- | --- | | Bugzilla Link | 449458 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Oct 31, 2014 07:35 EDT | | Modified | Mar 20, 2015 14:08 EDT | | Reporter | EPP Error Reports |
Description
Hello committers,
we received a new error report for Eclipse 4.5.0.I20140918-0330.
General Information:\ anonymous-id: ee6a7cf4-6277-45ce-b349-ac81306b3e3f\ eclipse-build-id: 4.5.0.I20140918-0330\ eclipse-product: org.eclipse.epp.package.modeling.product\ operating system: Windows7 6.1.0 (x86_64) - win32\ java-runtime-version: 1.7.0_45-b18
The following plug-ins were present on the execution stack (*):
Error Status:
Messages, stacktraces, and nested status objects may be shortened. Please visit \ http://dev.eclipse.org/recommenders/committers/confess/0.5/reports/-\ for the complete error log.
Some general information and guidelines about how to use this bug report:
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.
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.
Use the following resolutions for the following situations:
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.
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.
--