[Soot-list] Concurrent Analysis help - MhpAnalysis

Arnab De arnabde03 at gmail.com
Tue Jun 29 12:41:00 EDT 2010


Hi Eric,
In the same analysis, if we use Runnable instead of extending Thread,
the analysis returns all run methods for a start. Is there any way to
make it more precise?

Thanks,
Arnab

On Tue, Jun 29, 2010 at 9:54 PM, Eric Bodden
<bodden at st.informatik.tu-darmstadt.de> wrote:
> Hi again.
>
> The CallGraph will normally contain Thread-start edges from the
> statement that calls Thread.start() to all possible run-methods that
> could be called at this point.
>
> So if you have....
>
> Runnable r;
> if(p) r = new R1();
> else r = new R2();
> new Thread(r).start(); //s
>
> ... then you will get an edge from statement s to R1.run() and R2.run().
>
> Hope that helps,
>
> Eric
>
> --
> Dr. Eric Bodden
> Software Technology Group, Technische Universität Darmstadt, Germany
> Tel: +49 6151 16-5478    Fax: +49 6151 16-5410
> Mailing Address: S2|02 A209, Hochschulstraße 10, 64289 Darmstadt
>
>
>
> On 29 June 2010 12:30, Ankur Sinha <sanjay.ankur at gmail.com> wrote:
>> hi,
>>
>> I recently mailed with a query regarding getDeclaringClass. Eric's reply
>> clarified what it was about and unfortunately, it also clarified that
>> getDeclaringClass is not appropriate for what I'm trying to achieve. :(
>>
>> I've been digging into the MhpAnalysis that Soot provides.
>>
>> This is an excerpt from a paper titled : " Practical MHP Information
>> Analysis for Concurrent Java Programs" by Lin Li and Clark Verbrugge
>>
>>
>>> PEG edges fall into one of four different categories: local, start, wait and
>>> notify edges. The first three are statically constructed, and the last is created
>>> during the analysis. A local edge represents normal, intra-thread control flow, not
>>> dependent on thread communication. These edges are inherited from the base
>>> CFG, and are shown as solid edges in Figure 1. A start edge is created to indicate
>>> a must-precede relation between a call to Thread.start() and the first action
>>> of the initiated thread. These edges are shown in Figure 1 as the dotted edges
>>> with solid arrowheads between the (ti ,start,main) nodes and the corresponding
>>> (*,begin,ti ) node. A waiting edge models the control flow dependent on thread
>>> notification. These are inserted between waiting nodes and notified-entry nodes,
>>> and are shown as dotted edges with empty arrowheads in Figure 1.
>>>
>>
>> I have some queries:
>>
>> 1. Do I have access to these edges? i.e., can I use these in my programs
>> like I can use the kind() method to get THREAD edges, and therefore
>> their sources and targets?
>>
>> 2. I'm not too clear on the above definition of a start edge. Does it
>> mean :
>>
>> t1.start().
>>
>> ..
>> ..
>>
>>
>>
>> run()
>>
>> an edge between the t1.start() and the 1st stmt of the corresponding
>> run() or an edge between Thread.start() and $something(I'm not sure what
>> this $something is)?
>>
>> What I'm trying to get:
>>
>> I'm trying to get a HashMap<Unit,SootMethod> which stores the Units
>> calling the start() methods and the corresponding run() method, i.e.,
>> the Unit containing t1.start() and the specific run() method it calls.
>>
>> I'm still new to Soot so there's a high probability that I'm thinking of
>> it all wrong and that a much simpler method exists :)
>>
>> regards,
>> Ankur
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>


More information about the Soot-list mailing list