#21 ROT can get corrupted, leading to leaks and VM crashes

1.12 Accepted
closed-accepted
nobody
5
2007-03-25
2007-03-05
Andreas Junghans
No

In the current ROT implementation, the keys used for the ROT are created like this:

protected static Object getMapKey( Map targetMap, JacobObject o ) {
if ( targetMap instanceof WeakHashMap ) {
return o;
} else {
return new Integer( o.hashCode() );
}
}

This is problematic when com.jacob.autogc is false: o.hashCode() doesn't have to be unique, and in an application I'm writing, there actually are a few collisions (I'm dealing with many objects). These collisions leave some objects behind, which can even lead to VM crashes when they're collected after ComThread.Release() has been called.

To me, the different key and value handling for HashMap and WeakHashMap doesn't make sense. Maybe it's an artifact from the past?

The attached patch (relative to the 1.11.1 source) removes the getMapKey and getMapValue methods and always uses the object directly as the key and null as the value (both of which was already the case for WeakHashMap). After applying this patch, I don't have ROT-related leaks or crashes anymore.

Any objections to the patch?

Discussion

  • Patch for ROT.java against 1.11.1 source

     
    Attachments
  • clay_shooter
    clay_shooter
    2007-03-10

    Logged In: YES
    user_id=1189284
    Originator: NO

    This patch has been accepted and will make the 1.12 build.

    The hashmap key handling was a legacy from when the autogc handler was added. We didn't change the way the old (manual-gc) code worked.

     
  • clay_shooter
    clay_shooter
    2007-03-10

    • labels: --> Java-Com Commmunication
    • milestone: --> 1.12 Accepted
    • status: open --> pending-accepted
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
    • status: pending-accepted --> closed-accepted