• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L2
  • nrana
  • Reporter: jsamarziya
  • June 09, 2009
  • 0
  • Watchers: 3
  • August 20, 2009
  • June 10, 2009

Attachments

  • jsamarziya (2.00 k) application/x-zip-compressed bugtest.zip

Description

An overflow bug exists in PhysicalStateClassLoader#createGetObjectReferencesMethod (line 551). When the number of fields in a managed object is sufficiently large, the generated getObjectReferences() method attempts to invoke the HashSet constructor with an overflowed byte value. This results in a server crash when retrieval of the managed object is attempted.

java.lang.IllegalArgumentException: Illegal initial capacity: -128 at java.util.HashMap.(HashMap.java:172) at java.util.HashMap.(HashMap.java:199) at java.util.HashSet.(HashSet.java:125) at com.tc.state.idx1.ObjectWithFields_V1.getObjectReferences(Unknown Source) at com.tc.objectserver.managedobject.PhysicalManagedObjectState.addObjectReferencesTo(PhysicalManagedObjectState.java:112) at com.tc.objectserver.managedobject.ManagedObjectImpl.addObjectReferencesTo(ManagedObjectImpl.java:146) at com.tc.objectserver.managedobject.ManagedObjectTraverser.markProcessed(ManagedObjectTraverser.java:42) at com.tc.objectserver.managedobject.ManagedObjectTraverser.traverse(ManagedObjectTraverser.java:33) at com.tc.objectserver.impl.ObjectManagerImpl.addReachableObjectsIfNecessary(ObjectManagerImpl.java:521) at com.tc.objectserver.impl.ObjectManagerImpl.basicLookupObjectsFor(ObjectManagerImpl.java:497) at com.tc.objectserver.impl.ObjectManagerImpl.lookupObjectsForOptionallyCreate(ObjectManagerImpl.java:196) at com.tc.objectserver.impl.ObjectManagerImpl.lookupObjectsAndSubObjectsFor(ObjectManagerImpl.java:180) at com.tc.objectserver.impl.ObjectRequestManagerImpl.basicRequestObjects(ObjectRequestManagerImpl.java:119) at com.tc.objectserver.impl.ObjectRequestManagerImpl.splitAndRequestObjects(ObjectRequestManagerImpl.java:98) at com.tc.objectserver.impl.ObjectRequestManagerImpl.requestObjects(ObjectRequestManagerImpl.java:85) at com.tc.objectserver.impl.ObjectRequestManagerRestartImpl.requestObjects(ObjectRequestManagerRestartImpl.java:118) at com.tc.objectserver.handler.ManagedObjectRequestHandler.handleEventFromClient(ManagedObjectRequestHandler.java:93) at com.tc.objectserver.handler.ManagedObjectRequestHandler.handleEvent(ManagedObjectRequestHandler.java:52) at com.tc.async.impl.StageImpl$WorkerThread.run(StageImpl.java:142)

Comments

Tim Eck 2009-06-09

great find Jeffery! thanks for all the detail. Fix is easy, just need use a LDC instead there.

Did you happen upon this naturally with a real world class with that many fields, or some sort of benchmark testing? Just curious

Jeffrey Samarziya 2009-06-09

Yeah, we have a set of business objects that are generated from database schema metadata, and some of those have hundreds of fields. I just eventually happened upon the problem.

Fiona OShea 2009-06-10

Tim, think you have a workaround for this.

Tim Eck 2009-06-10

This is “partially” fixed. The new upper limit on fields should be ~1927 (as opposed to 127 before). There are more things to fix to get the limit to the class file supported max (which is 64k I believe)

Nitin Rana 2009-08-20

verified in 3.1 rev 13427 and trunk rev 13435