[Soot-list] FastHierarchy bug

[Eric Bodden]

Hi Tobias. Thanks for reporting this and for even providing a
solution. I just checked in a fix. I also emailed our admins again
about the Bugzilla.

The method-resolution code you mention seems to be not even used
within Soot itself. Hence I would handle it with care if I was you, as
it does apparently not get thoroughly tested.

Eric

2009/7/29 Tobias Gutzmann <tobias.gutzmann at vxu.se>:
> Hej,
>
> The bugzilla seems to have been down for a while, so I would like to
> keep this bugreport alive for the next release. It even comes with a
> solution to the problem ;-)
>
> consider the following program:
>
> abstract class BCDE { void foo() { } }
> class BCD extends BCDE {
>   void foo() { super.foo(); } // line 3
> }
>
> calling FastHierarchy.resolveSpecialDispatch() on the invokespecial instruction
> generated for the call on line 3 leads to a RuntimeException.
> Reason: resolveSpecialDispatch() calls resolveConcreteDispatch(), which then
> traverses the class hierarchy. If a superclass is abstract, then an exception is
> thrown. However, the code above is valid, so resolving the dispatch shouldn't be
> an issue; I think an exception should occur iff the method, not the
> class, is abstract. This should probably hold in general, so I think that
> resolveConcreteDispatch() has the bug, not resolveSpecialDispatch().
>
> Suggestion:
> - remove lines 468-471 in soot.FastHierarchy
> - add code: before returning a result method, check if the method is abstract.
> If so, throw an exception.
>
> best regards,
> Tobias
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden
Software Technology Group
Technical University Darmstadt, Germany