[Soot-list] java.lang.ref.Finalizer

[Ondrej Lhotak]

Hi Khilan...

There are some places where the call edges generated by Soot are not
exactly the same ones seen by *J, but the intent is to model the same
behaviour.

The one example that I remember is the doPrivileged method:
at run time, some method A calls doPrivileged, passing in an object, and
doPrivileged calls run on the object. The edge that Soot generates goes
from A directly to run, bypassing doPrivileged. This makes it possible
to model parameter passing: the native implementation of doPrivileged
passes its first parameter as the receiver of run. The result is that
probe will show a difference, but the overall effect on any analysis
is the same.

For java.lang.ref.Finalizer, I remember something similar, but I do not
remember the details.

Ondrej


On Tue, Mar 11, 2008 at 12:29:20PM +0000, Khilan Gudka wrote:
>    Dear All,
> 
>    I'm running soot + spark with Sun Java 1.5 with 1.3 libs
>    (rt.jar,tools.jar,sunrsasign.jar) prepended to the classpath. I've been
>    comparing static and dynamic call graphs (using probe with soot and starj)
>    and have a question about one particular edge that appears at run-time but
>    doesn't appear in spark's call graph:
> 
>    java.security.Security: initialize() ===> java.lang.ref.Finalizer:
>    register(Ljava/lang/Object;)
> 
>    The call to register(Object) exists because a FileInputStream is
>    constructed in initialize(), which has a finalize() method. Why does it
>    not appear in spark's call graph? This class isn't loaded by reflection,
>    so the -dynamic-class flag doesn't work, register(Object) is an implicit
>    invokation by the JVM.
> 
>    Any help would be greatly appreciated.
> 
>    Thanks,
>    Khilan

> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list