[Soot-list] bug with makeAllocNode?

[lpxz]

Hello Eric, Patric:
    I find out that the problem is brought by my own mistake.
    For some personal reason, I change the default equals() of
Object.java which was implemented using "==". I change the
implementation into hashCode() comparing. That is the reason why hashMap
would give unexpected results.

The original version is correct. 
Sorry for the inconvenience. 

and my version: the hashCode() based on type is not reliable here, 
because "new A()" in one method should be different from "new A()" in
another method. This can be guaranteed by the java native equals(). But
if using hashCode() based on the type, it would judge the two items as
the same, and corresponds to the same AllocNode. This would lead to
problems for the point-to analysis.

Thanks

Peng




在 2009-12-08二的 16:58 +0800，lpxz写道：
> Hello Eric, Pat:
>    Thank you for your reply, I also think the trace is strange because I
> can not explain about it. I will use the original version and try to
> figure out what is the real problem later.
> 
>   Thanks.
> 
> Peng
> 在 2009-12-08二的 09:26 +0100，Eric Bodden写道：
> > Hi Peng.
> > 
> > Patrick is right. The hashCode cannot be the problem. Two identical
> > hash codes on different objects are totally fine. All this will cause
> > is having both objects end up in the same bucket.
> > 
> > >     But based on this trace, JNewExpr "new java.io.DataInputStream
> > > hashcode:145892892" and "new java.lang.StringBuilder145892892 " have the
> > > same hashCode(), I can not understand this point, because I think their
> > > hashCode() is assigned based on the memory address. But this really happens,
> > > two objects are having the same hashCode, so "e.hash==hash" returns true.
> > > What is more, "e.key==key" returns true too, which is reflected from the
> > > execution trace.
> > 
> > That is absolutely impossible. Two different objects can never "==" each other.
> > 
> > Best wishes,
> > Eric
> 
>