Bugzilla – Full Text Bug Listing
| Summary: | Concurrent modification may occur due to lack of synchronization in schema for schemas. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Chris Simmons <cps> | ||||
| Component: | XSD | Assignee: | Ed Merks <Ed.Merks> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | ||||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
This was spotted happening by chance in real code, this just seemed the easiest and most reliable way to reproduce the problem. A work-around is to force initialisation of the schema-for-schemas somewhere like this:-
static {
// Force initialisation.
// https://bugs.eclipse.org/bugs/show_bug.cgi?id=328022
XSDSchema schemaForSchema = XSDUtil.getSchemaForSchema("http://www.w3.org/2001/XMLSchema");
schemaForSchema.validate();
}
Created attachment 187161 [details]
Patches to address the issue.
I imagine that if we assign the list of patterns at the end of the logic for populating it we can avoid problems with bad race conditions. There can still be race conditions, but it will no longer matter who wins. Would you be able to confirm this before I commit it?
Given the change is harmless and I'm pretty sure fixes the issue, I'll just commit it to CVS for 2.7. FWIW I tried reproducing the bug post-fix without doing so. I'm afraid I lost the project, I probably forgot to add a description when attaching it so bugzilla kindly threw it away. The fix is available in 2.7M7 or earlier. |
Build Identifier: M20100211-1343 XSD has a static schema for schemas instance which is shared and not under the client's control. It is used by XSD validation, for example, to perform NCName validation of the name attribute of xs:element declaration. Howeve, it has lazily initialised fields which are prone to result in ConcurrentModificationException. Reproducible: Sometimes Steps to Reproduce: 1. Open project attached as zip. 2. Add a breakpoint to halt the thread (not VM) in XSDPatternFacetImpl line 312 for (RegularExpression pattern : getPatterns(false)) 3. Set the breakpoint condition to this "thisWillBeValidatedAgainstTheNCNamePatternFacet".equals(value) 4. Now debug the test. It will halt both threads on this breakpoint, then restart the VM so that both threads start at the same time. After repeating this a few times I typically get an exception Caused by: java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.eclipse.xsd.impl.XSDPatternFacetImpl.isConstraintSatisfied(XSDPatternFacetImpl.java:312) at org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl$AssessmentImpl.validate(XSDSimpleTypeDefinitionImpl.java:3697) at org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.assess(XSDSimpleTypeDefinitionImpl.java:3911) at org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.assess(XSDSimpleTypeDefinitionImpl.java:3849) at org.eclipse.xsd.impl.XSDSimpleTypeDefinitionImpl.assess(XSDSimpleTypeDefinitionImpl.java:3844) at org.eclipse.xsd.impl.XSDConcreteComponentImpl.checkSimpleTypeConstraint(XSDConcreteComponentImpl.java:723) at org.eclipse.xsd.impl.XSDConcreteComponentImpl.checkBuiltInTypeConstraint(XSDConcreteComponentImpl.java:696) at org.eclipse.xsd.impl.XSDElementDeclarationImpl.validate(XSDElementDeclarationImpl.java:976) at org.eclipse.xsd.impl.XSDConcreteComponentImpl.validate(XSDConcreteComponentImpl.java:565) at org.eclipse.xsd.impl.XSDSchemaImpl.validate(XSDSchemaImpl.java:1653)