[Soot-list] bug with makeAllocNode?

[lpxz]

Hello pat:
    Yes,It's not fine for different objects to return true from equals().

     Yes,JNewExpr delegates to AbstractNewExpr.equivTo when executing equivTo, but the problem is JNewExpr's equals() and the hashCode() is not re-defined. So focusing on equals() and hashCode(), it have nothing to do with AbstractNewExpr (equivTo, equivHashCode() is not called here).

so when I call hashmap.get(), it  calls JnewExpr.hashCode() and equals(),  probably two newExpr with different types have the same hashCode, and get unexpected thing which it should not get.

    So we need to redefine hashCode() and equals() making use of equivTo, equivHashcode().

     I use soot2.3.0, Ubuntu 8.*. 
     I hacked the Object.java into hack.jar: add objectID field into it the corresponding Object.java. When each object is created, objectID ++ ; Then I run a program through java -Xbootclasspath/p:hack.jar xxx.
    
     This works well in my unit tests.
     While I do the same thing to soot, it throws the above exceptions. and I avoid them through redefining the hashcode() and equals().
     
     Can you tell me why this is the problem, I can not think of any reasons.
      

Regards
Peng






Patrick Lam wrote:
> lpxz wrote:
>   
>> Hello pat:
>>     Yes, I agree with you. the implementation of hashmap is through 
>> table[indexFor(hash, table.length)].
>>     and be refined through:  if (e.hash == hash && ((k = e.key) == key
>> || key.equals(k)))
>>
>>    But here, for newExpr, we only cares about the reftype, right?
>>    perviously in the hashmap, we have "new A()"-> AllocNode1
>>    while later we have "new B()", we do not want to retrieve out
>> AllocNode1. we want it return a null, and create a new AllocNode2.
>>     But here, "new B()" have the same hashcode as "new  A()" , so they
>> retrieve out the AllocNode1.
>>     and the following check would through runtimeException.I can not
>> quite explain here why two objects have the same native hashCode(). but
>> in my run, it would happen frequently, If I do not add
>> -Xbootclasspath/p:hack.jar
>> There would be no such problems. I can not explain this because the
>> Xbootclasspath seems have nothing to do with native hashCode().
>>
>>     Instread, we can make sure "new B()" does not have the same hashcode
>> as "new A()", we can achive this by hashing on the reftype's classname.
>> Then the exception is not thrown any more, "new B" would not retrieve
>> allocNode1 actually.
>>     
>
> I think that you're mis-diagnosing the root cause of the problem. The
> problem is that, for some reason, two different Java objects are
> returning true for equals(). It's perfectly fine for them to have the
> same hashCode, and I'm pretty sure that changing hashCode just masks the
> problem, without solving it. It's not fine for different objects to
> return true from equals().
>
> I looked at the implementation of equals() in JNewExpr, and that should
> never happen. Actually, JNewExpr delegates to AbstractNewExpr.equivTo,
> which is:
>
>     public boolean equivTo(Object o)
>     {
>         if (o instanceof AbstractNewExpr)
>         {
>             AbstractNewExpr ae = (AbstractNewExpr)o;
>             return type.equals(ae.type);
>         }
>         return false;
>     }
>
> so it should only return true for new statements with the same type,
> unless there's a bug in the equals() method for type.
>
> What is your system setup?
>
> pat
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20091208/3705e21f/attachment.html