[Soot-list] bug with makeAllocNode?

[Patrick Lam]

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