| Summary: | NPE with tracing enabled and checked "perf*" tracing options. | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Frieder Jacobi <extispex> |
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> |
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> |
| Severity: | minor | ||
| Priority: | P3 | ||
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
Moving all open problem reports to 4.0 Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!! Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Interesting, this problem must have been fixed by commit 3639bc6952869705555c88940bb9b73d4ce41a91 that changes the ConcurrentHashMap to an IdentityHashMap. Available in R20130613-1157 (4.2) |
Build Identifier: M20100909-0800 The exception is thrown in two scenarios: on the server side (A) as well as on the client side (B). The reason is the implementation of AbstractCDORevision.hashCode(), which is called right after the constructor and makes use of this.getId()/this.getBranch(), which return null. Unfortunately, none of the revision object's fields has a value other than 0/null, which makes the call of hashCode at this time kind of meaningless. But it is called, since the fresh revision has to be put into a hash map... The stack trace: java.lang.NullPointerException at org.eclipse.emf.cdo.spi.common.revision.AbstractCDORevision.hashCode(AbstractCDORevision.java:137) at java.util.concurrent.ConcurrentHashMap.put(Unknown Source) at org.eclipse.net4j.util.om.trace.PerfTracer.start(PerfTracer.java:34) at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.read(BaseCDORevision.java:127) at org.eclipse.emf.cdo.internal.common.protocol.CDODataInputImpl.readCDORevision(CDODataInputImpl.java:371) ... Reproducible: Always Steps to Reproduce: scenario A/server side: 1. Enable tracing for the run configuration of the server, check project "org.eclipse.emf.cdo.common (4.0.0)", check all of "perf*" in the right part. 2. Switch to CDO perspective. 3. In "CDO Sessions" view, create a new session, a transaction, and create a new resource in this transaction. 4. Commit this transaction: the NPE is thrown on server side. scenario B/client side: 1. Enable tracing for the run configuration of the client, check project "org.eclipse.emf.cdo.common (4.0.0)", check all of "perf*" in the right part. 2. Switch to CDO perspective. 3. In "CDO Sessions" view, create a new session. 4. Create a transaction: the NPE is thrown on client side.