[Soot-list] Potential bug fix for ThreadLocalObjectsAnalysis

[Khilan Gudka]

Hi,

Actually there is another bug. Here is my test case:

public class SimpleSharing {

    Object f;

    public static void main(String[] args) {

        final SimpleSharing x = new SimpleSharing();

        x.f = new Object();

        // share x
        (new Thread() {
            public void run() {
                x.f = null;
            }
        }).start();
    }

}


TLO says that x is thread-local and x.f is shared but x is shared here as
well?

Thanks,
Khilan

On 15 March 2011 13:33, Khilan Gudka <khilan at doc.ic.ac.uk> wrote:

> Hi,
>
> I think I have a potential bug fix for
> http://www.sable.mcgill.ca/pipermail/soot-list/2009-September/002504.html.
> It seems that the bug is due to an assumption that if an object is
> thread-local then all it's fields are also thread-local. This manifests
> itself in ClassLocalObjectsAnalysis.java with the call to
> setAllFieldsLocal() in the block:
>
> else if( SmartMethodLocalObjectsAnalysis.isObjectLocal(dfa,
> containingMethod, containingContext, iie.getBase()) )
>
> {
>
> // calling a method on a local object
>
> callingContext.setAllFieldsLocal();
>
> callingContext.setThisLocal();
>
> }
>
>
> However, Arie's test-case breaks this assumption because although publish
> is thread-local, publish.d isn't. Hence, I commented out the call to
> setAllFieldsLocal() and it is now giving the correct result, that publish is
> thread-local and publish.d is thread-shared.
>
>
> Please let me know if this is correct.
>
>
> Cheers,
>
> Khilan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20110315/fa9d7a24/attachment.html