From berber at tzi.de  Fri Dec  2 01:23:57 2011
From: berber at tzi.de (Bernhard Berger)
Date: Fri, 02 Dec 2011 07:23:57 +0100
Subject: [Soot-list] Question regarding Java Bytecode
Message-ID: <1322807037.22311.146.camel@stw2.informatik.uni-bremen.de>

Hi everybody,

today soot greeted me with a nice exception located somewhere deep in
the coffie-source. Since the bytecode I am analyzing is not generated by
a default java compiler the Bytecode might be the culprit. The stack
trace is the following one:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 6
 at soot.coffi.ByteCode.locateInstr(ByteCode.java:1104)
 at soot.coffi.ByteCode.locateInstr(ByteCode.java:1108)
 at soot.coffi.ByteCode.locateInstr(ByteCode.java:1108)
 at soot.coffi.ByteCode.locateInst(ByteCode.java:1097)
 at soot.coffi.ClassFile.parseMethod(ClassFile.java:1248)
 at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:78)
 at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
 at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
 at soot.PackManager.retrieveAllBodies(PackManager.java:989)
 at soot.PackManager.runPacks(PackManager.java:338)
 at soot.Main.run(Main.java:198)
 at soot.Main.main(Main.java:141) 

I took a look at the method's Bytecode and its exception table sind soot
handles links exception table to the corresponding Bytecode instructions
at this point. I think the Bytecode is not correct at this point but I'm
not a Bytecode expert. Perhaps someone can support my theory.

javap gives me the following output for the method in question:

public java.lang.String getPluginsPath();
  Code:
   0:   aload_0
   1:   monitorenter
   2:   aload_0
   3:   monitorexit
   4:   ldc     #209; //String 
   6:   areturn
  Exception table:
   from   to  target type
     2     2     7   any

I consulted the JVM-spec and it states for the exception table:
The value of the handler_pc (target in this case) item indicates the
start of the exception handler. The value of the item must be a valid
index into the code array and must be the index of the opcode of an
instruction.

Therefore the Bytecode is not corret, since the handler_pc does not
point to a valid address. Am I correct? If the Bytecode is invalid I am
going to blame the author of the tool that generated the Bytecode. :-)

Regards from Bremen, Germany

Bernhard 


From eric.bodden at ec-spride.de  Fri Dec  2 04:38:39 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 2 Dec 2011 10:38:39 +0100
Subject: [Soot-list] Question regarding Java Bytecode
In-Reply-To: <1322807037.22311.146.camel@stw2.informatik.uni-bremen.de>
References: <1322807037.22311.146.camel@stw2.informatik.uni-bremen.de>
Message-ID: <CALhVNNJhgtqOSD1fGLZdGEES9Oc8X3qaMcoi0S1nddQ8E4cG8g@mail.gmail.com>

Hi Bernhard.

Yes, to me this clearly looks like invalid bytecode. By the way,
usually you can easily find out whether bytecode is valid by just
passing the respective class to the "java" command. Even if the type
has no main method, the VM will invoke the bytecode verifier on it and
complain if the code is invalid.

Eric

2011/12/2 Bernhard Berger <berber at tzi.de>:
> Hi everybody,
>
> today soot greeted me with a nice exception located somewhere deep in
> the coffie-source. Since the bytecode I am analyzing is not generated by
> a default java compiler the Bytecode might be the culprit. The stack
> trace is the following one:
>
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 6
> ?at soot.coffi.ByteCode.locateInstr(ByteCode.java:1104)
> ?at soot.coffi.ByteCode.locateInstr(ByteCode.java:1108)
> ?at soot.coffi.ByteCode.locateInstr(ByteCode.java:1108)
> ?at soot.coffi.ByteCode.locateInst(ByteCode.java:1097)
> ?at soot.coffi.ClassFile.parseMethod(ClassFile.java:1248)
> ?at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:78)
> ?at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
> ?at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
> ?at soot.PackManager.retrieveAllBodies(PackManager.java:989)
> ?at soot.PackManager.runPacks(PackManager.java:338)
> ?at soot.Main.run(Main.java:198)
> ?at soot.Main.main(Main.java:141)
>
> I took a look at the method's Bytecode and its exception table sind soot
> handles links exception table to the corresponding Bytecode instructions
> at this point. I think the Bytecode is not correct at this point but I'm
> not a Bytecode expert. Perhaps someone can support my theory.
>
> javap gives me the following output for the method in question:
>
> public java.lang.String getPluginsPath();
> ?Code:
> ? 0: ? aload_0
> ? 1: ? monitorenter
> ? 2: ? aload_0
> ? 3: ? monitorexit
> ? 4: ? ldc ? ? #209; //String
> ? 6: ? areturn
> ?Exception table:
> ? from ? to ?target type
> ? ? 2 ? ? 2 ? ? 7 ? any
>
> I consulted the JVM-spec and it states for the exception table:
> The value of the handler_pc (target in this case) item indicates the
> start of the exception handler. The value of the item must be a valid
> index into the code array and must be the index of the opcode of an
> instruction.
>
> Therefore the Bytecode is not corret, since the handler_pc does not
> point to a valid address. Am I correct? If the Bytecode is invalid I am
> going to blame the author of the tool that generated the Bytecode. :-)
>
> Regards from Bremen, Germany
>
> Bernhard
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 32, 64293 Darmstadt

From christophe.foket at elis.ugent.be  Fri Dec  2 09:01:30 2011
From: christophe.foket at elis.ugent.be (Christophe Foket)
Date: Fri, 02 Dec 2011 15:01:30 +0100
Subject: [Soot-list] Jasmin annotation bug(fix)
In-Reply-To: <CALhVNNKG4==USvRJO+oCLr8wPGRBJW0kUnZ4JaFCCvq22OSsAQ@mail.gmail.com>
References: <4ED685AC.50404@elis.ugent.be>
	<CALhVNNKG4==USvRJO+oCLr8wPGRBJW0kUnZ4JaFCCvq22OSsAQ@mail.gmail.com>
Message-ID: <4ED8DA3A.7040909@elis.ugent.be>

Hi Eric,

There still seems to be an issue with the fix I posted before. The fact 
is that it will not work in case you have array annotations that 
actually have a name.

jasmin calls setNoName() at two different locations, both in 
jasmin.ClassFile:

    380          if (methAnnotDef != null){
    381              methAnnotDef.setNoName();
    382              currentMethod.addAnnotationDef(new 
AnnotationDefaultAttr(methAnnotDef));
    383          }

and

   1031      ElemValPair makeArrayElem(String name, char kind, Object list){
   1032          ArrayElemValPair elem = new ArrayElemValPair(name, 
kind, (ArrayList)list);
   1033          elem.setNoName();
   1034          return elem;
   1035      }

I confirmed that blindly calling setNoName() on an ArrayElemValPair can 
also result in corrupt bytecode if the annotation actually has a name. 
The easiest way to fix this would be to rewrite setNoName() in 
ArrayElemValPair once again to:

     public void setNoName(){
         if(name.uniq.equals("default")) // check if the annotation has 
no name
             super.setNoName();
         if (list == null) return;
         Iterator it = list.iterator();
         while (it.hasNext()){
             ((ElemValPair)it.next()).setNoName();
         }
     }

As a result, the name of the annotation will be omitted if it is not 
set. Note that the name "default" is used to signify that the annotation 
has no name. This is done in soot.coffi.Util when the class file is read 
during the initialization of soot. The createElementTags method, used to 
handle annotations, contains the following code:

    987      String elemName = "default";
    988      if (ev.name_index != 0){
    989          elemName = 
((CONSTANT_Utf8_info)coffiClass.constant_pool[ev.name_index]).convert();
    990      }

Annotations with no name have an ev.name_index of 0, and hence their 
name is set to "default".

I know that checking whether the name equals "default" is kind of hacky. 
Unfortunately, this is the only thing I could come up with for now, 
given my limited knowledge of jasmin.

Best,

Christophe

On 12/01/2011 05:52 PM, Eric Bodden wrote:
> Hello Christophe.
>
> Thanks a lot for this fix! I have just committed it.
>
> Your help is greatly appreciated.
>
> Best wishes,
> Eric
>
> On 30 November 2011 20:36, Christophe Foket
> <christophe.foket at elis.ugent.be>  wrote:
>> Hello,
>>
>> I am trying to run Soot on the tradebeans benchmark, which is part of the
>> latest dacapo release. For this, I am using the methodology described here:
>> http://www.bodden.de/2010/03/29/soot-tamiflex-dacapo/. One of the dumped
>> classes is "javax.persistence.OneToMany". This class is read in correctly by
>> soot, but written out incorrectly even if no transformations are applied to
>> it.
>>
>> The problem with this class is that there are two extra bytes inserted in
>> the annotation of one of its methods. Below is the output of "javap -verbose
>> javax.persistence.OneToMany" for both the original class and the
>> (untransformed) class generated by soot.
>>
>> Original:
>> =====
>>
>> public abstract javax.persistence.CascadeType[] cascade();
>>      Signature:
>> ()[Ljavax/persistence/CascadeType;
>>      AnnotationDefault: length =
>> 0x3
>>       5B 00
>> 00
>>
>> Sootified:
>> ======
>>
>> public abstract javax.persistence.CascadeType[]
>> cascade();
>>      Signature: ()[Ljavax/persistence/CascadeType;
>>      AnnotationDefault: length = 0x5
>>      00 17 5B 00 00
>>
>> Note that the 5B 00 00, corresponds to an array (5B is '[') of size zero,
>> which is what we expect. The "00 17", on the other hand points to an entry
>> in the constant pool, representing the name of the array annotation, which
>> is "default". After some debugging, I found out that the annotation is
>> internally represented by an ArrayElemValPair. ArrayElemValPair extends
>> ElemValPair, which defines a method setNoName() that, when called makes sure
>> that the constant pool index of the ElemValPair's name is not written out.
>> The problem, however, is in ArrayElemValPair, which overrides setNoName(),
>> without performing a super call:
>>
>>      public void setNoName(){
>>          if (list == null) return;
>>          Iterator it = list.iterator();
>>          while (it.hasNext()){
>>              ((ElemValPair)it.next()).setNoName();
>>          }
>>      }
>>
>> In this case, the setNoName() method is called on all elements of the list,
>> but not on the annotation itself. Therefore, whenever the annotation is
>> written out, it ithe constant pool index of its name is also written out.
>> Changing the implementation of setNoName() to
>>
>>      public void setNoName(){
>>          super.setNoName();
>>          if (list == null) return;
>>          Iterator it = list.iterator();
>>          while (it.hasNext()){
>>              ((ElemValPair)it.next()).setNoName();
>>          }
>>      }
>>
>> causes Soot to generate the class file correctly.
>>
>> I don't know enough about the internals of jasmin to decide whether or not
>> this fixes the issue entirely, but it at least seemed to solve my problem.
>>
>> Best,
>>
>> Christophe
>>
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>
>


From eric.bodden at ec-spride.de  Fri Dec  2 09:32:39 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 2 Dec 2011 15:32:39 +0100
Subject: [Soot-list] Jasmin annotation bug(fix)
In-Reply-To: <4ED8DA3A.7040909@elis.ugent.be>
References: <4ED685AC.50404@elis.ugent.be>
	<CALhVNNKG4==USvRJO+oCLr8wPGRBJW0kUnZ4JaFCCvq22OSsAQ@mail.gmail.com>
	<4ED8DA3A.7040909@elis.ugent.be>
Message-ID: <CALhVNNKiCN2Oinr3s3ZgLwsyXEqLOAMjOdjKSLL1PkUtjwqMOA@mail.gmail.com>

> I know that checking whether the name equals "default" is kind of hacky.
> Unfortunately, this is the only thing I could come up with for now, given my
> limited knowledge of jasmin.

Thanks again, Christophe. I will commit this fix. Many parts of jasmin
are kind of hacky, so don't worry :-)

Eric

From eric.bodden at ec-spride.de  Sun Dec  4 05:50:54 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Sun, 4 Dec 2011 11:50:54 +0100
Subject: [Soot-list] New context-sensitive points-to analysis in Soot
Message-ID: <CALhVNNLBQXYqp1gm2P2_WPnt=Q8=OsBz7Dzb58e7=LP7OY2BAg@mail.gmail.com>

Dear all,

Xiao (Richard) Xiao and Charles Zhang have presented at this year's
ISSTA a novel context-sensitive points-to analysis based on Spark that
is particularly efficient through a novel "geometric" encoding:
http://dx.doi.org/10.1145/2001420.2001443

I am happy to let you know that they have contributed their
implementation to Soot. It should be available in the next nightly
build (Dec. 5th):
http://vandyk.st.informatik.tu-darmstadt.de/abc/

Use the option "-ph cg.spark" to see the new phase options used to
enable and configure the analysis.

Richard and Charles, thanks a lot for this contribution!

Best wishes,
Eric
-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 32, 64293 Darmstadt

From eric.bodden at ec-spride.de  Wed Dec  7 04:05:27 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Wed, 7 Dec 2011 10:05:27 +0100
Subject: [Soot-list] SootResolver.bringToX...
Message-ID: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>

Hi all.

Today it's me who has a question :-)

I am having some students working on the SootResolver, and by looking
at the code I am getting more and more confused. I always thought that
the design was quite simple:

- bringToHierarchies loads a class up to its super classes and interfaces
- bringToSignatures loads methods and field signatures
- bringToBodies fills in the bodies
- All three methods load dependency classes to the required (lower levels).

But apparently, this is not quite the case. For instance, we find this
code in bringToSignatures:

    private void bringToSignatures(SootClass sc) {
        if(sc.resolvingLevel() >= SootClass.SIGNATURES ) return;
        bringToHierarchy(sc);
        sc.setResolvingLevel(SootClass.SIGNATURES);

        for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
            final SootField f = (SootField) fIt.next();
            addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
        }
   ...

As you can see here, this method iterates over all fields, which means
that at this point it assumes all field signatures to already be
present. In fact, the method does actually not do very much at all,
except adding dependencies to the worklist. In particular, it does not
really bring a class to signature level (except for changing the
resolving level).

Does anyone remember what was the intuition behind this?

Cheers,
Eric

From plam at sable.mcgill.ca  Wed Dec  7 12:50:50 2011
From: plam at sable.mcgill.ca (Patrick Lam)
Date: Wed, 07 Dec 2011 09:50:50 -0800
Subject: [Soot-list] SootResolver.bringToX...
In-Reply-To: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
References: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
Message-ID: <4EDFA77A.6080901@sable.mcgill.ca>

On 12/07/2011 01:05 AM, Eric Bodden wrote:
> Hi all.
>
> Today it's me who has a question :-)
>
> I am having some students working on the SootResolver, and by looking
> at the code I am getting more and more confused. I always thought that
> the design was quite simple:
>
> - bringToHierarchies loads a class up to its super classes and interfaces
> - bringToSignatures loads methods and field signatures
> - bringToBodies fills in the bodies
> - All three methods load dependency classes to the required (lower levels).
>
> But apparently, this is not quite the case. For instance, we find this
> code in bringToSignatures:
>
>      private void bringToSignatures(SootClass sc) {
>          if(sc.resolvingLevel()>= SootClass.SIGNATURES ) return;
>          bringToHierarchy(sc);
>          sc.setResolvingLevel(SootClass.SIGNATURES);
>
>          for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
>              final SootField f = (SootField) fIt.next();
>              addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
>          }
>     ...
>
> As you can see here, this method iterates over all fields, which means
> that at this point it assumes all field signatures to already be
> present. In fact, the method does actually not do very much at all,
> except adding dependencies to the worklist. In particular, it does not
> really bring a class to signature level (except for changing the
> resolving level).
>
> Does anyone remember what was the intuition behind this?

I don't really remember who rewrote the SootResolver, but it wasn't me.

I do remember some exposure to this code thouogh. I think that there's a 
surprising amount of work that gets done while the Jimple is being 
created (e.g. by Coffi).

Whenever Coffi loads a class, it will create the SootFields etc for that 
class. (See soot.coffi.util.resolveFromClassFile).

It looks to me like whenever Soot loads a class to the SIGNATURES level, 
then the classes for the types of fields of that class will exist. Look 
at the doc comment for the bringToSignatures method: to me, it says that 
the signatures already exist.

My guess, then, is as follows:

If class c is at level:
HIERARCHIES: there exists a SootClass for c
SIGNATURES: ... and all of the types for the fields of c also exist
BODIES: ... and the bodies also exist (I can no longer recall where they 
get created, but it's somewhere else.)

pat

From crysgirlro at yahoo.com  Wed Dec  7 15:02:28 2011
From: crysgirlro at yahoo.com (Cristina Ilie)
Date: Wed, 7 Dec 2011 12:02:28 -0800 (PST)
Subject: [Soot-list] Running with soot2.1
Message-ID: <1323288148.75503.YahooMailNeo@web161603.mail.bf1.yahoo.com>

Hello,

I need to test something in my tool with soot 2.1 but surprise: the same project with the same configuration (only the API is changed) doesn't run with soot 2.1, while it run successfully with soot 2.3 or 2.4. 


I'm receiving the error: couldn't find class: AppSource (is your soot-class-path set properly?). My soot-class-path is set and there is included the location of AppSource. What can I do? I observed that in 2.1 doesn't exista the functions loadBasicClasses() and loadClassAndSupport().

Please help.

Cristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111207/531fa9f2/attachment.html 

From crysgirlro at yahoo.com  Thu Dec  8 03:30:01 2011
From: crysgirlro at yahoo.com (Cristina Ilie)
Date: Thu, 8 Dec 2011 00:30:01 -0800 (PST)
Subject: [Soot-list] Scene.v().addBasicClass for soot 2.1
Message-ID: <1323333001.58131.YahooMailNeo@web161602.mail.bf1.yahoo.com>

Hi,


Does anyone know if it exists an equivalent for? Scene.v().addBasicClass(MyClass,SootClass.SIGNATURES); in soot 2.1? 

The addBasicClass method doesn't exist and SootClass doesn't have the SIGNATURES member. Now I'm receiving the 

following error [1]. 


Or can I find somewhere the API for 2.1?

[1] aused by: java.lang.RuntimeException: This operation requires resolving level SIGNATURES but 

MyClass is at resolving level HIERARCHY
If you are extending Soot, try to add the following call before calling soot.Main.main(..):
Scene.v().addBasicClass(MyClass,SIGNATURES);

Cristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111208/49440ba4/attachment.html 

From eric.bodden at ec-spride.de  Thu Dec  8 08:11:15 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 8 Dec 2011 14:11:15 +0100
Subject: [Soot-list] Running with soot2.1
In-Reply-To: <1323288148.75503.YahooMailNeo@web161603.mail.bf1.yahoo.com>
References: <1323288148.75503.YahooMailNeo@web161603.mail.bf1.yahoo.com>
Message-ID: <CALhVNNK4Rzv3YUF0T+cWNC2MNR_joSRQQjo8zdSZegSJUTH1dQ@mail.gmail.com>

Hi Cristina.

That's a little hard to say. There are a couple of years of
development between 2.1 and 2.3, and quite a few things may have been
improved in the class-loading process in the meantime. May I ask why
you have to use that old version?

Eric

On 7 December 2011 21:02, Cristina Ilie <crysgirlro at yahoo.com> wrote:
> Hello,
>
> I need to test something in my tool with soot 2.1 but surprise: the same
> project with the same configuration (only the API is changed) doesn't run
> with soot 2.1, while it run successfully with soot 2.3 or 2.4.
>
> I'm receiving the error: couldn't find class: AppSource (is your
> soot-class-path set properly?). My soot-class-path is set and there is
> included the location of AppSource. What can I do? I observed that in 2.1
> doesn't exista the functions loadBasicClasses() and loadClassAndSupport().
>
> Please help.
>
> Cristina
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From eric.bodden at ec-spride.de  Thu Dec  8 08:12:53 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 8 Dec 2011 14:12:53 +0100
Subject: [Soot-list] SootResolver.bringToX...
In-Reply-To: <4EDFA77A.6080901@sable.mcgill.ca>
References: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
	<4EDFA77A.6080901@sable.mcgill.ca>
Message-ID: <CALhVNNLYP++4rawxo8KfSqAvUxt4Sfo-iq5qF5A3vk8fL4hrUA@mail.gmail.com>

Thanks Patrick.

It seems that I misunderstood a bit the purpose of those methods (and
the different resolving levels). Apparently they are just about the
dependencies.

Cheers,
Eric

On 7 December 2011 18:50, Patrick Lam <plam at sable.mcgill.ca> wrote:
> On 12/07/2011 01:05 AM, Eric Bodden wrote:
>> Hi all.
>>
>> Today it's me who has a question :-)
>>
>> I am having some students working on the SootResolver, and by looking
>> at the code I am getting more and more confused. I always thought that
>> the design was quite simple:
>>
>> - bringToHierarchies loads a class up to its super classes and interfaces
>> - bringToSignatures loads methods and field signatures
>> - bringToBodies fills in the bodies
>> - All three methods load dependency classes to the required (lower levels).
>>
>> But apparently, this is not quite the case. For instance, we find this
>> code in bringToSignatures:
>>
>> ? ? ?private void bringToSignatures(SootClass sc) {
>> ? ? ? ? ?if(sc.resolvingLevel()>= SootClass.SIGNATURES ) return;
>> ? ? ? ? ?bringToHierarchy(sc);
>> ? ? ? ? ?sc.setResolvingLevel(SootClass.SIGNATURES);
>>
>> ? ? ? ? ?for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
>> ? ? ? ? ? ? ?final SootField f = (SootField) fIt.next();
>> ? ? ? ? ? ? ?addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
>> ? ? ? ? ?}
>> ? ? ...
>>
>> As you can see here, this method iterates over all fields, which means
>> that at this point it assumes all field signatures to already be
>> present. In fact, the method does actually not do very much at all,
>> except adding dependencies to the worklist. In particular, it does not
>> really bring a class to signature level (except for changing the
>> resolving level).
>>
>> Does anyone remember what was the intuition behind this?
>
> I don't really remember who rewrote the SootResolver, but it wasn't me.
>
> I do remember some exposure to this code thouogh. I think that there's a
> surprising amount of work that gets done while the Jimple is being
> created (e.g. by Coffi).
>
> Whenever Coffi loads a class, it will create the SootFields etc for that
> class. (See soot.coffi.util.resolveFromClassFile).
>
> It looks to me like whenever Soot loads a class to the SIGNATURES level,
> then the classes for the types of fields of that class will exist. Look
> at the doc comment for the bringToSignatures method: to me, it says that
> the signatures already exist.
>
> My guess, then, is as follows:
>
> If class c is at level:
> HIERARCHIES: there exists a SootClass for c
> SIGNATURES: ... and all of the types for the fields of c also exist
> BODIES: ... and the bodies also exist (I can no longer recall where they
> get created, but it's somewhere else.)
>
> pat
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From olhotak at uwaterloo.ca  Thu Dec  8 08:35:24 2011
From: olhotak at uwaterloo.ca (Ondrej Lhotak)
Date: Thu, 8 Dec 2011 08:35:24 -0500
Subject: [Soot-list] SootResolver.bringToX...
In-Reply-To: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
References: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
Message-ID: <20111208133524.GA3744@uwaterloo.ca>

The design of coffi requires that in order to bring some class C up to
level N, you must *first* bring all classes that C references up to
level N-1. In order to know which classes C references, you need to
bring C up to level N-1.

(In the above, the word "references" is overloaded: the definition of
what a class "references" changes depending on which level you are
trying to resolve it to.)

The system of worklists is designed to implement these rather tricky
constraints.

References can be recursive: C can reference C', and C' can also
reference C. The private bringToX methods are called from coffi when
resolving C. If they tried to resolve C' directly, then the process of
resolving of C' would then try to recursively resolve C, and you would
have infinite recursion.

The original Raja/Clark design of coffi and the SootResolver required
that you resolved all known classes to SIGNATURES first. It was then
safe to resolve any class of interest to BODIES. As class libraries grew
larger, resolving *everything* to SIGNATURES got very slow. (As well,
phantom classes were needed vrey frequently.) Running Soot on a single
class, even in non-whole-program mode, could easily take 30 seconds or
more. This was deemed unacceptable for the abc project. The options
were to rewrite coffi from the ground up (and possibly even change the
Jimple IR), or to build this complicated resolver to work around the
limitations of coffi's original design. We settled on the second option.

The -full-resolver option brings back the old resolve-everything
algorithm, if you're feeling nostalgic...

On Wed, Dec 07, 2011 at 10:05:27AM +0100, Eric Bodden wrote:
> Hi all.
> 
> Today it's me who has a question :-)
> 
> I am having some students working on the SootResolver, and by looking
> at the code I am getting more and more confused. I always thought that
> the design was quite simple:
> 
> - bringToHierarchies loads a class up to its super classes and interfaces
> - bringToSignatures loads methods and field signatures
> - bringToBodies fills in the bodies
> - All three methods load dependency classes to the required (lower levels).
> 
> But apparently, this is not quite the case. For instance, we find this
> code in bringToSignatures:
> 
>     private void bringToSignatures(SootClass sc) {
>         if(sc.resolvingLevel() >= SootClass.SIGNATURES ) return;
>         bringToHierarchy(sc);
>         sc.setResolvingLevel(SootClass.SIGNATURES);
> 
>         for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
>             final SootField f = (SootField) fIt.next();
>             addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
>         }
>    ...
> 
> As you can see here, this method iterates over all fields, which means
> that at this point it assumes all field signatures to already be
> present. In fact, the method does actually not do very much at all,
> except adding dependencies to the worklist. In particular, it does not
> really bring a class to signature level (except for changing the
> resolving level).
> 
> Does anyone remember what was the intuition behind this?
> 
> Cheers,
> Eric
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
> 

From eric.bodden at ec-spride.de  Thu Dec  8 09:13:15 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 8 Dec 2011 15:13:15 +0100
Subject: [Soot-list] SootResolver.bringToX...
In-Reply-To: <4EE0BEB3.6070503@cs.mcgill.ca>
References: <CALhVNN+tL2k2e-kXBdGMbChP8S=kmaM5vGLVt6TG2_Lt-x+kfw@mail.gmail.com>
	<20111208133524.GA3744@uwaterloo.ca> <4EE0BEB3.6070503@cs.mcgill.ca>
Message-ID: <CALhVNNK9c+5HBfD9rFsLXpEMccQw2gjD1DomxFX5N4AGBu0NDg@mail.gmail.com>

Thanks a lot Ondrej, that is quite helpful.

Good to know that somebody still remembers all these things :-)

Eric


> On 08/12/2011 8:35 AM, Ondrej Lhotak wrote:
>>
>> The design of coffi requires that in order to bring some class C up to
>> level N, you must *first* bring all classes that C references up to
>> level N-1. In order to know which classes C references, you need to
>> bring C up to level N-1.
>>
>> (In the above, the word "references" is overloaded: the definition of
>> what a class "references" changes depending on which level you are
>> trying to resolve it to.)
>>
>> The system of worklists is designed to implement these rather tricky
>> constraints.
>>
>> References can be recursive: C can reference C', and C' can also
>> reference C. The private bringToX methods are called from coffi when
>> resolving C. If they tried to resolve C' directly, then the process of
>> resolving of C' would then try to recursively resolve C, and you would
>> have infinite recursion.
>>
>> The original Raja/Clark design of coffi and the SootResolver required
>> that you resolved all known classes to SIGNATURES first. It was then
>> safe to resolve any class of interest to BODIES. As class libraries grew
>> larger, resolving *everything* to SIGNATURES got very slow. (As well,
>> phantom classes were needed vrey frequently.) Running Soot on a single
>> class, even in non-whole-program mode, could easily take 30 seconds or
>> more. This was deemed unacceptable for the abc project. The options
>> were to rewrite coffi from the ground up (and possibly even change the
>> Jimple IR), or to build this complicated resolver to work around the
>> limitations of coffi's original design. We settled on the second option.
>>
>> The -full-resolver option brings back the old resolve-everything
>> algorithm, if you're feeling nostalgic...
>>
>>
>> On Wed, Dec 07, 2011 at 10:05:27AM +0100, Eric Bodden wrote:
>>>
>>> Hi all.
>>>
>>> Today it's me who has a question :-)
>>>
>>> I am having some students working on the SootResolver, and by looking
>>> at the code I am getting more and more confused. I always thought that
>>> the design was quite simple:
>>>
>>> - bringToHierarchies loads a class up to its super classes and interfaces
>>> - bringToSignatures loads methods and field signatures
>>> - bringToBodies fills in the bodies
>>> - All three methods load dependency classes to the required (lower
>>> levels).
>>>
>>> But apparently, this is not quite the case. For instance, we find this
>>> code in bringToSignatures:
>>>
>>> ? ? private void bringToSignatures(SootClass sc) {
>>> ? ? ? ? if(sc.resolvingLevel()>= SootClass.SIGNATURES ) return;
>>> ? ? ? ? bringToHierarchy(sc);
>>> ? ? ? ? sc.setResolvingLevel(SootClass.SIGNATURES);
>>>
>>> ? ? ? ? for( Iterator fIt = sc.getFields().iterator(); fIt.hasNext(); ) {
>>> ? ? ? ? ? ? final SootField f = (SootField) fIt.next();
>>> ? ? ? ? ? ? addToResolveWorklist( f.getType(), SootClass.HIERARCHY );
>>> ? ? ? ? }
>>> ? ?...
>>>
>>> As you can see here, this method iterates over all fields, which means
>>> that at this point it assumes all field signatures to already be
>>> present. In fact, the method does actually not do very much at all,
>>> except adding dependencies to the worklist. In particular, it does not
>>> really bring a class to signature level (except for changing the
>>> resolving level).
>>>
>>> Does anyone remember what was the intuition behind this?
>>>
>>> Cheers,
>>> Eric
>>> _______________________________________________
>>> 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



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tanjiaqi at gmail.com  Thu Dec  8 09:27:39 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Thu, 8 Dec 2011 22:27:39 +0800
Subject: [Soot-list] How to have whole-program analysis run from non-main()
	methods
Message-ID: <CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>

Hi,

I am trying to explore the whole-program call-graph of a program
completely by flooding it, including from non-main() functions (even
if this will create disconnected components in the call-graph).

However, it seems that the current Soot whole-program analysis only
treats functions named as "main", or with a single String[] argument,
as main functions.

Is there any particular restriction that requires the whole-program
analysis to begin from a main(String[]) function (i.e. it is just
impossible to begin whole-program exploration from a non-main()
function)? Or is it just that an arbitrary exploration was never
developed?

Help would be much appreciated :)

Thanks!
Jiaqi Tan

From martinschaef at googlemail.com  Thu Dec  8 10:13:12 2011
From: martinschaef at googlemail.com (=?ISO-8859-1?Q?Martin_Sch=E4f?=)
Date: Thu, 8 Dec 2011 23:13:12 +0800
Subject: [Soot-list] boolean types in jimple
Message-ID: <CAPuqZKiFH7ibO76w_q+RytuYD6T26WwsHFjprooU_v_aBt1q5A@mail.gmail.com>

Hi,

I'm building a translation from jimple to boogie. Boogie cannot cast
between int and boolean, but in jimple all boolean are represented as
IntTypes.
Getting the boolean types by implementing a type checker would be
possible, but sounds like pain.

Is there a cheap way to check if something used to be a boolean?

Thanks,
M

From eric.bodden at ec-spride.de  Fri Dec  9 04:16:39 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 9 Dec 2011 10:16:39 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
Message-ID: <CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>

Hello.

Does this thread answer your questions?
http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html

Eric

On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
> Hi,
>
> I am trying to explore the whole-program call-graph of a program
> completely by flooding it, including from non-main() functions (even
> if this will create disconnected components in the call-graph).
>
> However, it seems that the current Soot whole-program analysis only
> treats functions named as "main", or with a single String[] argument,
> as main functions.
>
> Is there any particular restriction that requires the whole-program
> analysis to begin from a main(String[]) function (i.e. it is just
> impossible to begin whole-program exploration from a non-main()
> function)? Or is it just that an arbitrary exploration was never
> developed?
>
> Help would be much appreciated :)
>
> Thanks!
> Jiaqi Tan
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From eric.bodden at ec-spride.de  Fri Dec  9 04:21:48 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 9 Dec 2011 10:21:48 +0100
Subject: [Soot-list] boolean types in jimple
In-Reply-To: <20013_1323358733_pB8FcqUB008968_CAPuqZKiFH7ibO76w_q+RytuYD6T26WwsHFjprooU_v_aBt1q5A@mail.gmail.com>
References: <20013_1323358733_pB8FcqUB008968_CAPuqZKiFH7ibO76w_q+RytuYD6T26WwsHFjprooU_v_aBt1q5A@mail.gmail.com>
Message-ID: <CALhVNNJ-bOUeb2f9Rp_0Zx4RH4v231bb3WVze6iSDd-eEBGBxw@mail.gmail.com>

Hi Martin.

The problem is rather that bytecode contains only ints and no
booleans. Soot's type assigner does a pretty sophisticated range
analysis (looking at what range of numbers the int in question is
assigned) and actually *does* assign BooleanType.v() whenever the
range is {0,1}.

I just double-checked, the bytecode for the following Java method...

	public static void main(String[] args) {
		boolean b = true;
		if(b) {
			System.err.println(b);
		}
	}

... is translated to:

    public static void main(java.lang.String[])
    {
        java.lang.String[] r0;
        boolean z0;
        java.io.PrintStream $r1;

        r0 := @parameter0: java.lang.String[];
        z0 = 1;
        if z0 == 0 goto label0;

        $r1 = <java.lang.System: java.io.PrintStream err>;
        virtualinvoke $r1.<java.io.PrintStream: void println(boolean)>(z0);

     label0:
        return;
    }

Note the type boolean for z0.

Do you have any concrete examples where this should succeed but fails?

Eric

On 8 December 2011 16:13, Martin Sch?f <martinschaef at googlemail.com> wrote:
> Hi,
>
> I'm building a translation from jimple to boogie. Boogie cannot cast
> between int and boolean, but in jimple all boolean are represented as
> IntTypes.
> Getting the boolean types by implementing a type checker would be
> possible, but sounds like pain.
>
> Is there a cheap way to check if something used to be a boolean?
>
> Thanks,
> M
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tanjiaqi at gmail.com  Mon Dec 12 08:13:19 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Mon, 12 Dec 2011 21:13:19 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
Message-ID: <CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>

Hi Eric,

This is what I am currently doing:

1. Retrieve all methods from class to use as current entry-points
(begin exploring call-graph from one class of interest) using the
following:

Options.v().set_allow_phantom_refs(true);
PhaseOptions.v().setPhaseOption("jb", "enabled:true");
Scene.v().addBasicClass(className, SootClass.BODIES);
PackManager.v().runPacks();
SootClass c = Scene.v().loadClassAndSupport(className);

2. Set entry points:
List<SootMethod> entry = c.getMethods();
G.reset();
Options.v().set_whole_program(true); // same as "-w"
Options.v().set_allow_phantom_refs(true);
Options.v().set_app(true); // set application mode
Options.v().set_debug(true);
PhaseOptions.v().setPhaseOption("cg.cha", "enabled:true"); // true or off
Scene.v().setEntryPoints(entry);
Scene.v().loadNecessaryClasses();
PackManager.v().runPacks();		

3a. When I run with this, I get an error message that the main-class is not set:
Exception in thread "main" java.lang.RuntimeException: There is no
main class set!

3b. When I run it with "Scene.v().setMainClass(clazz);" added before
setting the entry-points, where clazz is the SootClass returned from
above, I get this error instead:
Exception in thread "main" java.lang.RuntimeException: Main-class has
no main method!

I'm not sure if I've missed something.

Thanks!
Jiaqi


On Fri, Dec 9, 2011 at 5:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Hello.
>
> Does this thread answer your questions?
> http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html
>
> Eric
>
> On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>> Hi,
>>
>> I am trying to explore the whole-program call-graph of a program
>> completely by flooding it, including from non-main() functions (even
>> if this will create disconnected components in the call-graph).
>>
>> However, it seems that the current Soot whole-program analysis only
>> treats functions named as "main", or with a single String[] argument,
>> as main functions.
>>
>> Is there any particular restriction that requires the whole-program
>> analysis to begin from a main(String[]) function (i.e. it is just
>> impossible to begin whole-program exploration from a non-main()
>> function)? Or is it just that an arbitrary exploration was never
>> developed?
>>
>> Help would be much appreciated :)
>>
>> Thanks!
>> Jiaqi Tan
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
>
> --
> Eric Bodden, Ph.D., http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Principal Investigator in Secure Services at CASED
> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From eric.bodden at ec-spride.de  Mon Dec 12 10:16:43 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Mon, 12 Dec 2011 16:16:43 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
Message-ID: <CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>

Hi Jiaqi.

It's surprising that you see "There is no main class set!". This
should not actually happen when custom entry points are defined. Could
you use a debugger to tell me in which context this message is raised,
i.e., in which context the method soot.Scene.getMainClass() is called?

Cheers,
Eric

On 12 December 2011 14:13, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
> Hi Eric,
>
> This is what I am currently doing:
>
> 1. Retrieve all methods from class to use as current entry-points
> (begin exploring call-graph from one class of interest) using the
> following:
>
> Options.v().set_allow_phantom_refs(true);
> PhaseOptions.v().setPhaseOption("jb", "enabled:true");
> Scene.v().addBasicClass(className, SootClass.BODIES);
> PackManager.v().runPacks();
> SootClass c = Scene.v().loadClassAndSupport(className);
>
> 2. Set entry points:
> List<SootMethod> entry = c.getMethods();
> G.reset();
> Options.v().set_whole_program(true); // same as "-w"
> Options.v().set_allow_phantom_refs(true);
> Options.v().set_app(true); // set application mode
> Options.v().set_debug(true);
> PhaseOptions.v().setPhaseOption("cg.cha", "enabled:true"); // true or off
> Scene.v().setEntryPoints(entry);
> Scene.v().loadNecessaryClasses();
> PackManager.v().runPacks();
>
> 3a. When I run with this, I get an error message that the main-class is not set:
> Exception in thread "main" java.lang.RuntimeException: There is no
> main class set!
>
> 3b. When I run it with "Scene.v().setMainClass(clazz);" added before
> setting the entry-points, where clazz is the SootClass returned from
> above, I get this error instead:
> Exception in thread "main" java.lang.RuntimeException: Main-class has
> no main method!
>
> I'm not sure if I've missed something.
>
> Thanks!
> Jiaqi
>
>
> On Fri, Dec 9, 2011 at 5:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> Hello.
>>
>> Does this thread answer your questions?
>> http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html
>>
>> Eric
>>
>> On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>> Hi,
>>>
>>> I am trying to explore the whole-program call-graph of a program
>>> completely by flooding it, including from non-main() functions (even
>>> if this will create disconnected components in the call-graph).
>>>
>>> However, it seems that the current Soot whole-program analysis only
>>> treats functions named as "main", or with a single String[] argument,
>>> as main functions.
>>>
>>> Is there any particular restriction that requires the whole-program
>>> analysis to begin from a main(String[]) function (i.e. it is just
>>> impossible to begin whole-program exploration from a non-main()
>>> function)? Or is it just that an arbitrary exploration was never
>>> developed?
>>>
>>> Help would be much appreciated :)
>>>
>>> Thanks!
>>> Jiaqi Tan
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>>
>>
>> --
>> Eric Bodden, Ph.D., http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Principal Investigator in Secure Services at CASED
>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tanjiaqi at gmail.com  Mon Dec 12 11:20:00 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Tue, 13 Dec 2011 00:20:00 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
Message-ID: <CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>

Hi Eric,

Here is the stack trace:
Exception in thread "main" java.lang.RuntimeException: There is no
main class set!
        at soot.Scene.getMainClass(Scene.java:160)
        at soot.EntryPoints.application(EntryPoints.java:65)
        at soot.EntryPoints.all(EntryPoints.java:95)
        at soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:43)
        at soot.Pack.apply(Pack.java:114)
        at soot.PackManager.runWholeProgramPacks(PackManager.java:408)
        at soot.PackManager.runPacks(PackManager.java:329)

Does this help?

Thanks,
Jiaqi

On Mon, Dec 12, 2011 at 11:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Hi Jiaqi.
>
> It's surprising that you see "There is no main class set!". This
> should not actually happen when custom entry points are defined. Could
> you use a debugger to tell me in which context this message is raised,
> i.e., in which context the method soot.Scene.getMainClass() is called?
>
> Cheers,
> Eric
>
> On 12 December 2011 14:13, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>> Hi Eric,
>>
>> This is what I am currently doing:
>>
>> 1. Retrieve all methods from class to use as current entry-points
>> (begin exploring call-graph from one class of interest) using the
>> following:
>>
>> Options.v().set_allow_phantom_refs(true);
>> PhaseOptions.v().setPhaseOption("jb", "enabled:true");
>> Scene.v().addBasicClass(className, SootClass.BODIES);
>> PackManager.v().runPacks();
>> SootClass c = Scene.v().loadClassAndSupport(className);
>>
>> 2. Set entry points:
>> List<SootMethod> entry = c.getMethods();
>> G.reset();
>> Options.v().set_whole_program(true); // same as "-w"
>> Options.v().set_allow_phantom_refs(true);
>> Options.v().set_app(true); // set application mode
>> Options.v().set_debug(true);
>> PhaseOptions.v().setPhaseOption("cg.cha", "enabled:true"); // true or off
>> Scene.v().setEntryPoints(entry);
>> Scene.v().loadNecessaryClasses();
>> PackManager.v().runPacks();
>>
>> 3a. When I run with this, I get an error message that the main-class is not set:
>> Exception in thread "main" java.lang.RuntimeException: There is no
>> main class set!
>>
>> 3b. When I run it with "Scene.v().setMainClass(clazz);" added before
>> setting the entry-points, where clazz is the SootClass returned from
>> above, I get this error instead:
>> Exception in thread "main" java.lang.RuntimeException: Main-class has
>> no main method!
>>
>> I'm not sure if I've missed something.
>>
>> Thanks!
>> Jiaqi
>>
>>
>> On Fri, Dec 9, 2011 at 5:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>> Hello.
>>>
>>> Does this thread answer your questions?
>>> http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html
>>>
>>> Eric
>>>
>>> On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I am trying to explore the whole-program call-graph of a program
>>>> completely by flooding it, including from non-main() functions (even
>>>> if this will create disconnected components in the call-graph).
>>>>
>>>> However, it seems that the current Soot whole-program analysis only
>>>> treats functions named as "main", or with a single String[] argument,
>>>> as main functions.
>>>>
>>>> Is there any particular restriction that requires the whole-program
>>>> analysis to begin from a main(String[]) function (i.e. it is just
>>>> impossible to begin whole-program exploration from a non-main()
>>>> function)? Or is it just that an arbitrary exploration was never
>>>> developed?
>>>>
>>>> Help would be much appreciated :)
>>>>
>>>> Thanks!
>>>> Jiaqi Tan
>>>> _______________________________________________
>>>> Soot-list mailing list
>>>> Soot-list at sable.mcgill.ca
>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>
>>>
>>>
>>> --
>>> Eric Bodden, Ph.D., http://bodden.de/
>>> Head of Secure Software Engineering Group at EC SPRIDE
>>> Principal Investigator in Secure Services at CASED
>>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
>
>
> --
> Eric Bodden, Ph.D., http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Principal Investigator in Secure Services at CASED
> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From eric.bodden at ec-spride.de  Mon Dec 12 11:31:14 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Mon, 12 Dec 2011 17:31:14 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
	<CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
Message-ID: <CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>

Yes, actually that did help, thanks. It appears that the method
soot.jimple.toolkits.callgraph.CallGraphPack.internalApply() is
missing a crucial check to avoid overriding the entry points you set.

Can you try replacing...

   	        if(!options.implicit_entry()) {
	            Scene.v().setEntryPoints(EntryPoints.v().application());
	        }
	        if( options.all_reachable() ) {
	            List<SootMethod> entryPoints = new ArrayList<SootMethod>();
	            entryPoints.addAll( EntryPoints.v().all() );
	            entryPoints.addAll(
EntryPoints.v().methodsOfApplicationClasses() );
	            Scene.v().setEntryPoints( entryPoints );
	        }

...by...

        if(!Scene.v().hasCustomEntryPoints()) {
            //original code
        }

? Does this help? If yes, then I can commit this change to the repository.

Eric

On 12 December 2011 17:20, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
> Hi Eric,
>
> Here is the stack trace:
> Exception in thread "main" java.lang.RuntimeException: There is no
> main class set!
> ? ? ? ?at soot.Scene.getMainClass(Scene.java:160)
> ? ? ? ?at soot.EntryPoints.application(EntryPoints.java:65)
> ? ? ? ?at soot.EntryPoints.all(EntryPoints.java:95)
> ? ? ? ?at soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:43)
> ? ? ? ?at soot.Pack.apply(Pack.java:114)
> ? ? ? ?at soot.PackManager.runWholeProgramPacks(PackManager.java:408)
> ? ? ? ?at soot.PackManager.runPacks(PackManager.java:329)
>
> Does this help?
>
> Thanks,
> Jiaqi
>
> On Mon, Dec 12, 2011 at 11:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> Hi Jiaqi.
>>
>> It's surprising that you see "There is no main class set!". This
>> should not actually happen when custom entry points are defined. Could
>> you use a debugger to tell me in which context this message is raised,
>> i.e., in which context the method soot.Scene.getMainClass() is called?
>>
>> Cheers,
>> Eric
>>
>> On 12 December 2011 14:13, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>> Hi Eric,
>>>
>>> This is what I am currently doing:
>>>
>>> 1. Retrieve all methods from class to use as current entry-points
>>> (begin exploring call-graph from one class of interest) using the
>>> following:
>>>
>>> Options.v().set_allow_phantom_refs(true);
>>> PhaseOptions.v().setPhaseOption("jb", "enabled:true");
>>> Scene.v().addBasicClass(className, SootClass.BODIES);
>>> PackManager.v().runPacks();
>>> SootClass c = Scene.v().loadClassAndSupport(className);
>>>
>>> 2. Set entry points:
>>> List<SootMethod> entry = c.getMethods();
>>> G.reset();
>>> Options.v().set_whole_program(true); // same as "-w"
>>> Options.v().set_allow_phantom_refs(true);
>>> Options.v().set_app(true); // set application mode
>>> Options.v().set_debug(true);
>>> PhaseOptions.v().setPhaseOption("cg.cha", "enabled:true"); // true or off
>>> Scene.v().setEntryPoints(entry);
>>> Scene.v().loadNecessaryClasses();
>>> PackManager.v().runPacks();
>>>
>>> 3a. When I run with this, I get an error message that the main-class is not set:
>>> Exception in thread "main" java.lang.RuntimeException: There is no
>>> main class set!
>>>
>>> 3b. When I run it with "Scene.v().setMainClass(clazz);" added before
>>> setting the entry-points, where clazz is the SootClass returned from
>>> above, I get this error instead:
>>> Exception in thread "main" java.lang.RuntimeException: Main-class has
>>> no main method!
>>>
>>> I'm not sure if I've missed something.
>>>
>>> Thanks!
>>> Jiaqi
>>>
>>>
>>> On Fri, Dec 9, 2011 at 5:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>>> Hello.
>>>>
>>>> Does this thread answer your questions?
>>>> http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html
>>>>
>>>> Eric
>>>>
>>>> On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I am trying to explore the whole-program call-graph of a program
>>>>> completely by flooding it, including from non-main() functions (even
>>>>> if this will create disconnected components in the call-graph).
>>>>>
>>>>> However, it seems that the current Soot whole-program analysis only
>>>>> treats functions named as "main", or with a single String[] argument,
>>>>> as main functions.
>>>>>
>>>>> Is there any particular restriction that requires the whole-program
>>>>> analysis to begin from a main(String[]) function (i.e. it is just
>>>>> impossible to begin whole-program exploration from a non-main()
>>>>> function)? Or is it just that an arbitrary exploration was never
>>>>> developed?
>>>>>
>>>>> Help would be much appreciated :)
>>>>>
>>>>> Thanks!
>>>>> Jiaqi Tan
>>>>> _______________________________________________
>>>>> Soot-list mailing list
>>>>> Soot-list at sable.mcgill.ca
>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>
>>>>
>>>>
>>>> --
>>>> Eric Bodden, Ph.D., http://bodden.de/
>>>> Head of Secure Software Engineering Group at EC SPRIDE
>>>> Principal Investigator in Secure Services at CASED
>>>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>>
>>
>>
>> --
>> Eric Bodden, Ph.D., http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Principal Investigator in Secure Services at CASED
>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tirunkel at informatik.uni-bremen.de  Tue Dec 13 05:11:57 2011
From: tirunkel at informatik.uni-bremen.de (Tillmann)
Date: Tue, 13 Dec 2011 11:11:57 +0100
Subject: [Soot-list] Getting line-number/type-informations at initialization
 via Jimple from bytecode
Message-ID: <4EE724ED.7030803@informatik.uni-bremen.de>

Hi,

today i have a problem to get informations about the initialisation of a 
variable. I need to find the src-line where the variable of a special 
type is initialized. In my example below i need the line- and 
type-information of the Java-source (3: String str = null;). In the 
corresponding Jimple (generated from class!) the equivalent line is  (9: 
n1 = null;) where "n1" is "null_type" in the corresponding unit 
@internalTransform the line-number is available, but not the type (in my 
example java.lang.String) and as proved this information isn't provided 
by the JimpleLocals @body.getLocals(). The long and the short of it: I 
need the information that "r1 is initalized by n1 in src-line 3" (lines 
10 and 8 in Jimple). I think these informations must be available from 
bytecode compiled with "-g".

Is there a known way to get these informations about line 3 in my 
Java-Example?

Thanks.

Tillmann

------ Java:

1    public String doSomething(){
2       Item x = null;
3       String str = null;
4       if (true){
5           str = x.toString();
6           str.concat("");
7       }
8    return str;
9    }

------ Jimple:

  1   public java.lang.String doSomething()
  2   {
  3      de.tirunkel.da.examples.Test r0;
  4       null_type n0, n1;
  5       java.lang.String r1;
  6
  7       r0 := @this: de.tirunkel.da.examples.Test;
  8       n0 = null;
  9       n1 = null;
  10     r1 = virtualinvoke n0.<java.lang.Object: java.lang.String 
toString()>();
  11     virtualinvoke r1.<java.lang.String: java.lang.String 
concat(java.lang.String)>("");
  12     return r1;
  13  }


From eric.bodden at ec-spride.de  Tue Dec 13 06:35:03 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Tue, 13 Dec 2011 12:35:03 +0100
Subject: [Soot-list] Getting line-number/type-informations at
 initialization via Jimple from bytecode
In-Reply-To: <4EE724ED.7030803@informatik.uni-bremen.de>
References: <4EE724ED.7030803@informatik.uni-bremen.de>
Message-ID: <CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>

Hi Tillmann.

One thing you could try is to use "-p jb keep-original-names:on". This
will cause Soot to try to pack together locals that have the same
name.

In general, the problem you are seeing is caused by the fact that
bytecode has no local variables, just stack locations.

Eric

On 13 December 2011 11:11, Tillmann <tirunkel at informatik.uni-bremen.de> wrote:
> Hi,
>
> today i have a problem to get informations about the initialisation of a
> variable. I need to find the src-line where the variable of a special
> type is initialized. In my example below i need the line- and
> type-information of the Java-source (3: String str = null;). In the
> corresponding Jimple (generated from class!) the equivalent line is ?(9:
> n1 = null;) where "n1" is "null_type" in the corresponding unit
> @internalTransform the line-number is available, but not the type (in my
> example java.lang.String) and as proved this information isn't provided
> by the JimpleLocals @body.getLocals(). The long and the short of it: I
> need the information that "r1 is initalized by n1 in src-line 3" (lines
> 10 and 8 in Jimple). I think these informations must be available from
> bytecode compiled with "-g".
>
> Is there a known way to get these informations about line 3 in my
> Java-Example?
>
> Thanks.
>
> Tillmann
>
> ------ Java:
>
> 1 ? ?public String doSomething(){
> 2 ? ? ? Item x = null;
> 3 ? ? ? String str = null;
> 4 ? ? ? if (true){
> 5 ? ? ? ? ? str = x.toString();
> 6 ? ? ? ? ? str.concat("");
> 7 ? ? ? }
> 8 ? ?return str;
> 9 ? ?}
>
> ------ Jimple:
>
> ?1 ? public java.lang.String doSomething()
> ?2 ? {
> ?3 ? ? ?de.tirunkel.da.examples.Test r0;
> ?4 ? ? ? null_type n0, n1;
> ?5 ? ? ? java.lang.String r1;
> ?6
> ?7 ? ? ? r0 := @this: de.tirunkel.da.examples.Test;
> ?8 ? ? ? n0 = null;
> ?9 ? ? ? n1 = null;
> ?10 ? ? r1 = virtualinvoke n0.<java.lang.Object: java.lang.String
> toString()>();
> ?11 ? ? virtualinvoke r1.<java.lang.String: java.lang.String
> concat(java.lang.String)>("");
> ?12 ? ? return r1;
> ?13 ?}
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tirunkel at informatik.uni-bremen.de  Tue Dec 13 07:40:52 2011
From: tirunkel at informatik.uni-bremen.de (Tillmann)
Date: Tue, 13 Dec 2011 13:40:52 +0100
Subject: [Soot-list] Getting line-number/type-informations at
 initialization via Jimple from bytecode
In-Reply-To: <CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>
References: <4EE724ED.7030803@informatik.uni-bremen.de>
	<CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>
Message-ID: <4EE747D4.5090900@informatik.uni-bremen.de>

Hi Eric,

thanks for your quick response.

I've tried "Options.v().setPhaseOption("jb","use-original-names:on");" 
the option seems to be applied correctly (is set in 
"soot.coffi.CoffiMethodSource.getBody(SootMethod, String)"), but with no 
effect on the jimple-bodies. The Bytecode is compiled with names (see 
below - gathered from eclipse-class-inspection).

But it's not a huge amount of work for me to create a work-around in my 
source-transformation-process.

       0  iconst_0
       1  istore_2 [flag]
       2  aconst_null
       3  astore_3 [client]
       4  aconst_null
       5  astore 4 [home]

Am 13.12.2011 12:35, schrieb Eric Bodden:
> Hi Tillmann.
>
> One thing you could try is to use "-p jb keep-original-names:on". This
> will cause Soot to try to pack together locals that have the same
> name.
>
> In general, the problem you are seeing is caused by the fact that
> bytecode has no local variables, just stack locations.


From tirunkel at informatik.uni-bremen.de  Tue Dec 13 08:36:31 2011
From: tirunkel at informatik.uni-bremen.de (Tillmann)
Date: Tue, 13 Dec 2011 14:36:31 +0100
Subject: [Soot-list] Getting line-number/type-informations at
 initialization via Jimple from bytecode
In-Reply-To: <4EE747D4.5090900@informatik.uni-bremen.de>
References: <4EE724ED.7030803@informatik.uni-bremen.de>
	<CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>
	<4EE747D4.5090900@informatik.uni-bremen.de>
Message-ID: <4EE754DF.8040402@informatik.uni-bremen.de>

Hi,

it's me again. I found out that there is possible a failiure in the CFG 
processing

if(!Util.v().useFaithfulNaming || la == null) in lines 891 & 920 
@soot.coffi.CFG.java

in my opinion must be without "!" -> if(Util.v().useFaithfulNaming || la 
== null). I've tried this and the names from local variable table are 
allocated correctly in "name"! But unfortunately i got Exceptions 
afterwards because the names obviously aren't connected properly :(

java.lang.RuntimeException: Variable r4 used without definition!
     at 
soot.jimple.toolkits.scalar.CopyPropagator.internalTransform(CopyPropagator.java:145)

by following the useFaithfulNaming variable i also altered the negation:

if(!useFaithfulNaming && activeVariableTable != null) in 
getLocalForIndex(JimpleBody listBody, int index) @soot.coffi.Util in 
line 817.

Afterwards everything seemed to be okay (the name switched from "l0" to 
"realVariableName"), but in internalTransform() in my jtp.x-pack the 
JimpleBody looks like before (names are: r0, r1, ...) .

Regards.

Tillmann


Am 13.12.2011 13:40, schrieb Tillmann:
> Hi Eric,
>
> thanks for your quick response.
>
> I've tried "Options.v().setPhaseOption("jb","use-original-names:on");"
> the option seems to be applied correctly (is set in
> "soot.coffi.CoffiMethodSource.getBody(SootMethod, String)"), but with no
> effect on the jimple-bodies. The Bytecode is compiled with names (see
> below - gathered from eclipse-class-inspection).
>
> But it's not a huge amount of work for me to create a work-around in my
> source-transformation-process.
>
>         0  iconst_0
>         1  istore_2 [flag]
>         2  aconst_null
>         3  astore_3 [client]
>         4  aconst_null
>         5  astore 4 [home]
>
> Am 13.12.2011 12:35, schrieb Eric Bodden:
>> Hi Tillmann.
>>
>> One thing you could try is to use "-p jb keep-original-names:on". This
>> will cause Soot to try to pack together locals that have the same
>> name.
>>
>> In general, the problem you are seeing is caused by the fact that
>> bytecode has no local variables, just stack locations.


From tirunkel at informatik.uni-bremen.de  Tue Dec 13 09:17:42 2011
From: tirunkel at informatik.uni-bremen.de (Tillmann)
Date: Tue, 13 Dec 2011 15:17:42 +0100
Subject: [Soot-list] Getting line-number/type-informations at
 initialization via Jimple from bytecode
In-Reply-To: <4EE754DF.8040402@informatik.uni-bremen.de>
References: <4EE724ED.7030803@informatik.uni-bremen.de>
	<CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>
	<4EE747D4.5090900@informatik.uni-bremen.de>
	<4EE754DF.8040402@informatik.uni-bremen.de>
Message-ID: <4EE75E86.5060803@informatik.uni-bremen.de>

Hi,

sorry for Spam:

Options.v().setPhaseOption("jb","use-original-names:true")

is still the best solution for my problem :) the "on"-parameter is not interpreted as true in JBOptions. Sorry for the trouble!

Regards.

Tillmann


Am 13.12.2011 14:36, schrieb Tillmann:
> Hi,
>
> it's me again. I found out that there is possible a failiure in the CFG
> processing
>
> if(!Util.v().useFaithfulNaming || la == null) in lines 891&  920
> @soot.coffi.CFG.java
>
> in my opinion must be without "!" ->  if(Util.v().useFaithfulNaming || la
> == null). I've tried this and the names from local variable table are
> allocated correctly in "name"! But unfortunately i got Exceptions
> afterwards because the names obviously aren't connected properly :(
>
> java.lang.RuntimeException: Variable r4 used without definition!
>       at
> soot.jimple.toolkits.scalar.CopyPropagator.internalTransform(CopyPropagator.java:145)
>
> by following the useFaithfulNaming variable i also altered the negation:
>
> if(!useFaithfulNaming&&  activeVariableTable != null) in
> getLocalForIndex(JimpleBody listBody, int index) @soot.coffi.Util in
> line 817.
>
> Afterwards everything seemed to be okay (the name switched from "l0" to
> "realVariableName"), but in internalTransform() in my jtp.x-pack the
> JimpleBody looks like before (names are: r0, r1, ...) .
>
> Regards.
>
> Tillmann
>
>
> Am 13.12.2011 13:40, schrieb Tillmann:
>> Hi Eric,
>>
>> thanks for your quick response.
>>
>> I've tried "Options.v().setPhaseOption("jb","use-original-names:on");"
>> the option seems to be applied correctly (is set in
>> "soot.coffi.CoffiMethodSource.getBody(SootMethod, String)"), but with no
>> effect on the jimple-bodies. The Bytecode is compiled with names (see
>> below - gathered from eclipse-class-inspection).
>>
>> But it's not a huge amount of work for me to create a work-around in my
>> source-transformation-process.
>>
>>          0  iconst_0
>>          1  istore_2 [flag]
>>          2  aconst_null
>>          3  astore_3 [client]
>>          4  aconst_null
>>          5  astore 4 [home]
>>
>> Am 13.12.2011 12:35, schrieb Eric Bodden:
>>> Hi Tillmann.
>>>
>>> One thing you could try is to use "-p jb keep-original-names:on". This
>>> will cause Soot to try to pack together locals that have the same
>>> name.
>>>
>>> In general, the problem you are seeing is caused by the fact that
>>> bytecode has no local variables, just stack locations.
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list


From eric.bodden at ec-spride.de  Tue Dec 13 09:36:04 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Tue, 13 Dec 2011 15:36:04 +0100
Subject: [Soot-list] Getting line-number/type-informations at
 initialization via Jimple from bytecode
In-Reply-To: <4EE75E86.5060803@informatik.uni-bremen.de>
References: <4EE724ED.7030803@informatik.uni-bremen.de>
	<CALhVNN+bR52z4ej7VUP_8ykHHq9O7K6bYGA=Z_4v+09GkWigkQ@mail.gmail.com>
	<4EE747D4.5090900@informatik.uni-bremen.de>
	<4EE754DF.8040402@informatik.uni-bremen.de>
	<4EE75E86.5060803@informatik.uni-bremen.de>
Message-ID: <CALhVNNJXmmb3crJn_5OS7kgEXeHW7MMavaGbUMO+xMxEb+bSOA@mail.gmail.com>

> the "on"-parameter is not interpreted as true in JBOptions. Sorry for the trouble!

Oh - my bad. Sorry about that. So the comments on the class CFG are obsolete?

Eric

From eric.bodden at ec-spride.de  Tue Dec 13 11:26:10 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Tue, 13 Dec 2011 17:26:10 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQ==fK2oVqcD30LW9+FYJHUxDi_XYWGGzF7f1u0fObeS1g@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
	<CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
	<CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>
	<CAP9EXQ==fK2oVqcD30LW9+FYJHUxDi_XYWGGzF7f1u0fObeS1g@mail.gmail.com>
Message-ID: <CALhVNN+u4DS+aLRmEUb-uujgQ53sES553MVhSgG9tA1pqCWH=w@mail.gmail.com>

> I'm working off of soot-2.4.0 and it seems that Scene does not have a
> hasCustomEntryPoints() method, should I be working off the nightly
> instead?

Yes please. We specifically added this method to deal with issues like
the one you are having.

Eric

From tanjiaqi at gmail.com  Tue Dec 13 11:22:40 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Wed, 14 Dec 2011 00:22:40 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
	<CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
	<CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>
Message-ID: <CAP9EXQ==fK2oVqcD30LW9+FYJHUxDi_XYWGGzF7f1u0fObeS1g@mail.gmail.com>

Hi,

I'm working off of soot-2.4.0 and it seems that Scene does not have a
hasCustomEntryPoints() method, should I be working off the nightly
instead?

Thanks,
Jiaqi

On Tue, Dec 13, 2011 at 12:31 AM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Yes, actually that did help, thanks. It appears that the method
> soot.jimple.toolkits.callgraph.CallGraphPack.internalApply() is
> missing a crucial check to avoid overriding the entry points you set.
>
> Can you try replacing...
>
> ? ? ? ? ? ? ? ?if(!options.implicit_entry()) {
> ? ? ? ? ? ? ? ? ? ?Scene.v().setEntryPoints(EntryPoints.v().application());
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?if( options.all_reachable() ) {
> ? ? ? ? ? ? ? ? ? ?List<SootMethod> entryPoints = new ArrayList<SootMethod>();
> ? ? ? ? ? ? ? ? ? ?entryPoints.addAll( EntryPoints.v().all() );
> ? ? ? ? ? ? ? ? ? ?entryPoints.addAll(
> EntryPoints.v().methodsOfApplicationClasses() );
> ? ? ? ? ? ? ? ? ? ?Scene.v().setEntryPoints( entryPoints );
> ? ? ? ? ? ? ? ?}
>
> ...by...
>
> ? ? ? ?if(!Scene.v().hasCustomEntryPoints()) {
> ? ? ? ? ? ?//original code
> ? ? ? ?}
>
> ? Does this help? If yes, then I can commit this change to the repository.
>
> Eric
>
> On 12 December 2011 17:20, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>> Hi Eric,
>>
>> Here is the stack trace:
>> Exception in thread "main" java.lang.RuntimeException: There is no
>> main class set!
>> ? ? ? ?at soot.Scene.getMainClass(Scene.java:160)
>> ? ? ? ?at soot.EntryPoints.application(EntryPoints.java:65)
>> ? ? ? ?at soot.EntryPoints.all(EntryPoints.java:95)
>> ? ? ? ?at soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:43)
>> ? ? ? ?at soot.Pack.apply(Pack.java:114)
>> ? ? ? ?at soot.PackManager.runWholeProgramPacks(PackManager.java:408)
>> ? ? ? ?at soot.PackManager.runPacks(PackManager.java:329)
>>
>> Does this help?
>>
>> Thanks,
>> Jiaqi
>>
>> On Mon, Dec 12, 2011 at 11:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>> Hi Jiaqi.
>>>
>>> It's surprising that you see "There is no main class set!". This
>>> should not actually happen when custom entry points are defined. Could
>>> you use a debugger to tell me in which context this message is raised,
>>> i.e., in which context the method soot.Scene.getMainClass() is called?
>>>
>>> Cheers,
>>> Eric
>>>
>>> On 12 December 2011 14:13, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>>> Hi Eric,
>>>>
>>>> This is what I am currently doing:
>>>>
>>>> 1. Retrieve all methods from class to use as current entry-points
>>>> (begin exploring call-graph from one class of interest) using the
>>>> following:
>>>>
>>>> Options.v().set_allow_phantom_refs(true);
>>>> PhaseOptions.v().setPhaseOption("jb", "enabled:true");
>>>> Scene.v().addBasicClass(className, SootClass.BODIES);
>>>> PackManager.v().runPacks();
>>>> SootClass c = Scene.v().loadClassAndSupport(className);
>>>>
>>>> 2. Set entry points:
>>>> List<SootMethod> entry = c.getMethods();
>>>> G.reset();
>>>> Options.v().set_whole_program(true); // same as "-w"
>>>> Options.v().set_allow_phantom_refs(true);
>>>> Options.v().set_app(true); // set application mode
>>>> Options.v().set_debug(true);
>>>> PhaseOptions.v().setPhaseOption("cg.cha", "enabled:true"); // true or off
>>>> Scene.v().setEntryPoints(entry);
>>>> Scene.v().loadNecessaryClasses();
>>>> PackManager.v().runPacks();
>>>>
>>>> 3a. When I run with this, I get an error message that the main-class is not set:
>>>> Exception in thread "main" java.lang.RuntimeException: There is no
>>>> main class set!
>>>>
>>>> 3b. When I run it with "Scene.v().setMainClass(clazz);" added before
>>>> setting the entry-points, where clazz is the SootClass returned from
>>>> above, I get this error instead:
>>>> Exception in thread "main" java.lang.RuntimeException: Main-class has
>>>> no main method!
>>>>
>>>> I'm not sure if I've missed something.
>>>>
>>>> Thanks!
>>>> Jiaqi
>>>>
>>>>
>>>> On Fri, Dec 9, 2011 at 5:16 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>>>> Hello.
>>>>>
>>>>> Does this thread answer your questions?
>>>>> http://www.sable.mcgill.ca/pipermail/soot-list/2011-July/003799.html
>>>>>
>>>>> Eric
>>>>>
>>>>> On 8 December 2011 15:27, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to explore the whole-program call-graph of a program
>>>>>> completely by flooding it, including from non-main() functions (even
>>>>>> if this will create disconnected components in the call-graph).
>>>>>>
>>>>>> However, it seems that the current Soot whole-program analysis only
>>>>>> treats functions named as "main", or with a single String[] argument,
>>>>>> as main functions.
>>>>>>
>>>>>> Is there any particular restriction that requires the whole-program
>>>>>> analysis to begin from a main(String[]) function (i.e. it is just
>>>>>> impossible to begin whole-program exploration from a non-main()
>>>>>> function)? Or is it just that an arbitrary exploration was never
>>>>>> developed?
>>>>>>
>>>>>> Help would be much appreciated :)
>>>>>>
>>>>>> Thanks!
>>>>>> Jiaqi Tan
>>>>>> _______________________________________________
>>>>>> Soot-list mailing list
>>>>>> Soot-list at sable.mcgill.ca
>>>>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Eric Bodden, Ph.D., http://bodden.de/
>>>>> Head of Secure Software Engineering Group at EC SPRIDE
>>>>> Principal Investigator in Secure Services at CASED
>>>>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>>>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>>>
>>>
>>>
>>> --
>>> Eric Bodden, Ph.D., http://bodden.de/
>>> Head of Secure Software Engineering Group at EC SPRIDE
>>> Principal Investigator in Secure Services at CASED
>>> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>
>
>
> --
> Eric Bodden, Ph.D., http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Principal Investigator in Secure Services at CASED
> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From tanjiaqi at gmail.com  Wed Dec 14 09:21:36 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Wed, 14 Dec 2011 22:21:36 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNN+u4DS+aLRmEUb-uujgQ53sES553MVhSgG9tA1pqCWH=w@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
	<CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
	<CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>
	<CAP9EXQ==fK2oVqcD30LW9+FYJHUxDi_XYWGGzF7f1u0fObeS1g@mail.gmail.com>
	<CALhVNN+u4DS+aLRmEUb-uujgQ53sES553MVhSgG9tA1pqCWH=w@mail.gmail.com>
Message-ID: <CAP9EXQnt6Kf_QGzvRrJgU7B0M-d=7h5mNSYfwhC2ktkMcwdBEg@mail.gmail.com>

Hi,

Yes, it works now after the addition, the whole-program analysis is
able to proceed, although I'm facing other issues now which are
unrelated to the custom entry points used for callgraph generation.

Thanks!
Jiaqi

On Wed, Dec 14, 2011 at 12:26 AM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> I'm working off of soot-2.4.0 and it seems that Scene does not have a
>> hasCustomEntryPoints() method, should I be working off the nightly
>> instead?
>
> Yes please. We specifically added this method to deal with issues like
> the one you are having.
>
> Eric

From berber at informatik.uni-bremen.de  Wed Dec 14 10:27:16 2011
From: berber at informatik.uni-bremen.de (berber)
Date: Wed, 14 Dec 2011 16:27:16 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQnt6Kf_QGzvRrJgU7B0M-d=7h5mNSYfwhC2ktkMcwdBEg@mail.gmail.com>
References: <12317_1323360482_pB8G82HM005425_CAP9EXQm-CY9FamdGTzj_d+7z5VYPMFXmSD2kEOqeEehNkhogWg@mail.gmail.com>
	<CALhVNNJ+OmrQoa1=u5Uq6G_A27GLN6nf6m_AgUgjF8-Xn7-8tA@mail.gmail.com>
	<CAP9EXQ=kAjvR6vqk0tD+_wcLeS8RTsJu7YiMoxFQAomLZHkEYw@mail.gmail.com>
	<CALhVNNKSpvzYszhX6bCgT9ZGS2B+mBzdcVsRsq238QKF=frHhw@mail.gmail.com>
	<CAP9EXQkK3MFDaC40uV=nrTPjikbo8pByE7Bt+g=6-xKDXzJ_RA@mail.gmail.com>
	<CALhVNNJiag_dO1B3Q1a9m5+aZRzWLF6oC6pM64v57FNM61xE6A@mail.gmail.com>
	<CAP9EXQ==fK2oVqcD30LW9+FYJHUxDi_XYWGGzF7f1u0fObeS1g@mail.gmail.com>
	<CALhVNN+u4DS+aLRmEUb-uujgQ53sES553MVhSgG9tA1pqCWH=w@mail.gmail.com>
	<CAP9EXQnt6Kf_QGzvRrJgU7B0M-d=7h5mNSYfwhC2ktkMcwdBEg@mail.gmail.com>
Message-ID: <f42956c0d6663b36a68838f1d3b3ca8a@webmail.informatik.uni-bremen.de>

Hi Jiaqi,

which are the issues you have observed? Some days ago I tried to 
construct a call-graph, using Spark, for a program with custom 
entry-points and observed, that there were several calls missing. I used 
some non-static methods as entry points and Spark were not able to 
resolve all calls starting from this particular class. Especially calls 
within the class were missing (perhaps Spark did not have any 
information about "this").

Would be glad, if you could share the experiences you made.

Bernhard


> Hi,
>
> Yes, it works now after the addition, the whole-program analysis is
> able to proceed, although I'm facing other issues now which are
> unrelated to the custom entry points used for callgraph generation.
>
> Thanks!
> Jiaqi
>
> On Wed, Dec 14, 2011 at 12:26 AM, Eric Bodden
> <eric.bodden at ec-spride.de> wrote:
>>> I'm working off of soot-2.4.0 and it seems that Scene does not have 
>>> a
>>> hasCustomEntryPoints() method, should I be working off the nightly
>>> instead?
>>
>> Yes please. We specifically added this method to deal with issues 
>> like
>> the one you are having.
>>
>> Eric
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list


From tanjiaqi at gmail.com  Thu Dec 15 11:31:57 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Fri, 16 Dec 2011 00:31:57 +0800
Subject: [Soot-list] How to have whole-program analysis run from non-main()
	methods
Message-ID: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>

Hi Bernhard,

Yes I did have a non-static entry point with this signature:

int performIO(ByteBuffer buf) throws IOException {
     return channel.read(buf);
}

Here is the error:

Exception in thread "main"
soot.jimple.toolkits.typing.integer.InternalTypingException
	at soot.jimple.toolkits.typing.integer.ClassHierarchy.typeNode(ClassHierarchy.java:178)
	at soot.jimple.toolkits.typing.integer.TypeResolver.typeVariable(TypeResolver.java:109)
	at soot.jimple.toolkits.typing.integer.ConstraintCollector.caseReturnStmt(ConstraintCollector.java:942)
	at soot.jimple.internal.JReturnStmt.apply(JReturnStmt.java:98)
	at soot.jimple.toolkits.typing.integer.ConstraintCollector.collect(ConstraintCollector.java:48)
	at soot.jimple.toolkits.typing.integer.TypeResolver.collect_constraints_1(TypeResolver.java:227)
	at soot.jimple.toolkits.typing.integer.TypeResolver.resolve_step_1(TypeResolver.java:180)
	at soot.jimple.toolkits.typing.integer.TypeResolver.resolve(TypeResolver.java:140)
	at soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:140)
	at soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
	at soot.BodyTransformer.transform(BodyTransformer.java:51)
	at soot.Transform.apply(Transform.java:104)
	at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
	at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
	at soot.Pack.apply(Pack.java:124)
	at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
	at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:83)
	at soot.SootMethod.retrieveActiveBody(SootMethod.java:316)
	at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod(OnFlyCallGraphBuilder.java:531)
	at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables(OnFlyCallGraphBuilder.java:426)
	at soot.jimple.toolkits.callgraph.CallGraphBuilder.build(CallGraphBuilder.java:84)
	at soot.jimple.toolkits.callgraph.CHATransformer.internalTransform(CHATransformer.java:43)
	at soot.SceneTransformer.transform(SceneTransformer.java:39)
	at soot.Transform.apply(Transform.java:89)
	at soot.RadioScenePack.internalApply(RadioScenePack.java:57)
	at soot.jimple.toolkits.callgraph.CallGraphPack.internalApply(CallGraphPack.java:51)
	at soot.Pack.apply(Pack.java:114)
	at soot.PackManager.runWholeProgramPacks(PackManager.java:417)
	at soot.PackManager.runPacks(PackManager.java:336)

I have not looked closely at this so it's possible that I made a
mistake somewhere.

I'm also doing something that I'm not sure is entirely correct: I
first ran Soot with whole-program mode disabled, and resolved the
class whose methods I want to use as EntryPoints up to BODIES. This
allowed me to get a SootClass with the fully populated SootMethod's
which I then used to populate the List<Method> to set EntryPoints.
Then, before I performed the whole-program analysis, I ran G.reset()
before running the regular Soot setup and running the

Was your experience similar? Did you have a similar usage or face
similar issues?

Thanks,
Jiaqi

From eric.bodden at ec-spride.de  Thu Dec 15 11:45:17 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 15 Dec 2011 17:45:17 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
References: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
Message-ID: <CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>

Hi Jiaqi.

On 15 December 2011 17:31, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
> I'm also doing something that I'm not sure is entirely correct: I
> first ran Soot with whole-program mode disabled, and resolved the
> class whose methods I want to use as EntryPoints up to BODIES. This
> allowed me to get a SootClass with the fully populated SootMethod's
> which I then used to populate the List<Method> to set EntryPoints.
> Then, before I performed the whole-program analysis, I ran G.reset()
> before running the regular Soot setup and running the

I don't think this is unsound, but using the wjpp pack is a simpler
way to do this. This pack runs after class resolution but before the
cg pack:

		PackManager.v().getPack("wjpp").add(new Transform("wjpp.foo",new
SceneTransformer() {
			
			@SuppressWarnings("rawtypes")
			protected void internalTransform(String phaseName, Map options) {
				G.v().out.println("Using all concrete methods of all application
classes as entry points.");
				List<SootMethod> entryPoints = new LinkedList<SootMethod>();
				for(SootClass c: Scene.v().getApplicationClasses()) {
					for(SootMethod m: c.getMethods()) {
						if(m.isConcrete()) {
							entryPoints.add(m);
						}
					}
				}
				
				G.v().out.println(entryPoints.size() + " entry points.");
				
				Scene.v().setEntryPoints(entryPoints);
			}
		}));

Eric

From tanjiaqi at gmail.com  Thu Dec 15 17:34:20 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Fri, 16 Dec 2011 06:34:20 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>
References: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
	<CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>
Message-ID: <CAP9EXQ=E4Hnkrp6Xs9Ea1=vfQ9Ub1zDf0s=UEVu=yfHF6Vw2MQ@mail.gmail.com>

Hi Eric,

Does the wjpp pack run before the call-graph construction starts? Do all
packs happen before call-graph construction?

Thanks,
Jiaqi

On Fri, Dec 16, 2011 at 12:45 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:

> Hi Jiaqi.
>
> On 15 December 2011 17:31, Jiaqi Tan <tanjiaqi at gmail.com> wrote:
> > I'm also doing something that I'm not sure is entirely correct: I
> > first ran Soot with whole-program mode disabled, and resolved the
> > class whose methods I want to use as EntryPoints up to BODIES. This
> > allowed me to get a SootClass with the fully populated SootMethod's
> > which I then used to populate the List<Method> to set EntryPoints.
> > Then, before I performed the whole-program analysis, I ran G.reset()
> > before running the regular Soot setup and running the
>
> I don't think this is unsound, but using the wjpp pack is a simpler
> way to do this. This pack runs after class resolution but before the
> cg pack:
>
>                PackManager.v().getPack("wjpp").add(new
> Transform("wjpp.foo",new
> SceneTransformer() {
>
>                        @SuppressWarnings("rawtypes")
>                        protected void internalTransform(String phaseName,
> Map options) {
>                                G.v().out.println("Using all concrete
> methods of all application
> classes as entry points.");
>                                List<SootMethod> entryPoints = new
> LinkedList<SootMethod>();
>                                for(SootClass c:
> Scene.v().getApplicationClasses()) {
>                                        for(SootMethod m: c.getMethods()) {
>                                                if(m.isConcrete()) {
>                                                        entryPoints.add(m);
>                                                }
>                                        }
>                                }
>
>                                G.v().out.println(entryPoints.size() + "
> entry points.");
>
>                                Scene.v().setEntryPoints(entryPoints);
>                        }
>                }));
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111216/4a87e4bb/attachment.html 

From eric.bodden at ec-spride.de  Fri Dec 16 03:03:46 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 16 Dec 2011 09:03:46 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQ=E4Hnkrp6Xs9Ea1=vfQ9Ub1zDf0s=UEVu=yfHF6Vw2MQ@mail.gmail.com>
References: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
	<CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>
	<CAP9EXQ=E4Hnkrp6Xs9Ea1=vfQ9Ub1zDf0s=UEVu=yfHF6Vw2MQ@mail.gmail.com>
Message-ID: <CALhVNNK4HTX9Zphd3ME3ecR+VQsaceMnZ=g9+7FHn0Qu-xk8oA@mail.gmail.com>

Hi.

> Does the wjpp pack run before the call-graph construction starts?

Yes.

> Do all
> packs happen before call-graph construction?

No. All other w* packs run after the cg phase. That's why we
introduced the wjpp: to allow things to be done *before* the call
graph is constructed.

Eric

From tanjiaqi at gmail.com  Fri Dec 16 03:12:04 2011
From: tanjiaqi at gmail.com (Jiaqi Tan)
Date: Fri, 16 Dec 2011 16:12:04 +0800
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CALhVNNK4HTX9Zphd3ME3ecR+VQsaceMnZ=g9+7FHn0Qu-xk8oA@mail.gmail.com>
References: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
	<CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>
	<CAP9EXQ=E4Hnkrp6Xs9Ea1=vfQ9Ub1zDf0s=UEVu=yfHF6Vw2MQ@mail.gmail.com>
	<CALhVNNK4HTX9Zphd3ME3ecR+VQsaceMnZ=g9+7FHn0Qu-xk8oA@mail.gmail.com>
Message-ID: <CAP9EXQkAY6F8hcgyqgWgGmXnVoWC_gHY5veED4ZuPHdEzHL8wQ@mail.gmail.com>

Hi,

How does Soot decide which classes to load and resolve? All of my
classes are in one JAR file. Currently I have a set of classes with
known entry-points with static main() functions, but I also have
another set of classes which I suspect are reachable only via
reflection. Assuming that the reflection calls are not reflected due
to the unsoundness introduced, then my call-graph should consist of
unconnected components, with one set reachable from the static main()
functions, and the other reachable through other methods, e.g. the
functions registered with the reflection API.

But if I use addBasicClass() on the classes with the main() functions,
then will the other classes not reachable without reflection be added
to the worklist of classes to resolve? Because if the other classes
which are in the JAR but are not reachable are not added to the
worklist, then even the suggested wjpp transform() would not add the
methods in those classes as entry points?

Second (unrelated) question: Is wjpp a new pack not available in 2.4.0?

Thanks!
Jiaqi

On Fri, Dec 16, 2011 at 4:03 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Hi.
>
>> Does the wjpp pack run before the call-graph construction starts?
>
> Yes.
>
>> Do all
>> packs happen before call-graph construction?
>
> No. All other w* packs run after the cg phase. That's why we
> introduced the wjpp: to allow things to be done *before* the call
> graph is constructed.
>
> Eric

From eric.bodden at ec-spride.de  Fri Dec 16 03:54:21 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 16 Dec 2011 09:54:21 +0100
Subject: [Soot-list] How to have whole-program analysis run from
 non-main() methods
In-Reply-To: <CAP9EXQkAY6F8hcgyqgWgGmXnVoWC_gHY5veED4ZuPHdEzHL8wQ@mail.gmail.com>
References: <CAP9EXQnEqsG=68Vkd=A9ySBQbfyXqUiu2ZY286WeXZdsj3UBug@mail.gmail.com>
	<CALhVNNKF_UAB72TP=cWK0bOe=HLBmOs8Yu3f_HJfXYZjB4SoNQ@mail.gmail.com>
	<CAP9EXQ=E4Hnkrp6Xs9Ea1=vfQ9Ub1zDf0s=UEVu=yfHF6Vw2MQ@mail.gmail.com>
	<CALhVNNK4HTX9Zphd3ME3ecR+VQsaceMnZ=g9+7FHn0Qu-xk8oA@mail.gmail.com>
	<CAP9EXQkAY6F8hcgyqgWgGmXnVoWC_gHY5veED4ZuPHdEzHL8wQ@mail.gmail.com>
Message-ID: <CALhVNNJtPV5rT+0aOEUn0LQQsYtDB1L5zmgR0avOaGX+dspVZg@mail.gmail.com>

Hi.

> How does Soot decide which classes to load and resolve?

In whole-program mode I believe it will load the entire transitive
closure of the entry points (plus any application classes you may have
given, see here: http://www.sable.mcgill.ca/soot/tutorial/usage/).

> All of my
> classes are in one JAR file. Currently I have a set of classes with
> known entry-points with static main() functions, but I also have
> another set of classes which I suspect are reachable only via
> reflection. Assuming that the reflection calls are not reflected due
> to the unsoundness introduced, then my call-graph should consist of
> unconnected components, with one set reachable from the static main()
> functions, and the other reachable through other methods, e.g. the
> functions registered with the reflection API.

Well, classes/methods that are only accessed through reflection will
not be taken into account at all unless you use TamiFlex in
combination with Soot.

> But if I use addBasicClass() on the classes with the main() functions,
> then will the other classes not reachable without reflection be added
> to the worklist of classes to resolve?

Yes, they should be resolved but nothing else, really. They will still
not be reachable in your call graph and hence a whole-program analysis
will likely not be doing anything with those classes.

> Because if the other classes
> which are in the JAR but are not reachable are not added to the
> worklist, then even the suggested wjpp transform() would not add the
> methods in those classes as entry points?

In this case it would make sense to just add all classes in the JAR as
application classes, for instance using the process-dir option. That
way, they will be resolved for sure.

> Second (unrelated) question: Is wjpp a new pack not available in 2.4.0?

Probably not. It also is a recent addition. We should really do a new release...

Eric

From rule1_ at hotmail.com  Sat Dec 17 02:12:12 2011
From: rule1_ at hotmail.com (Rule One)
Date: Sat, 17 Dec 2011 01:12:12 -0600
Subject: [Soot-list] Some changes
Message-ID: <COL113-W650C5C944A3ED1FDFB2080AFA10@phx.gbl>


I was having difficulties loading some classes using Soot, here are the changes I made to the source code (could someone verify if these are correct? I have absolutely no experience in Soot):
Index: src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java===================================================================--- src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java	(revision 3600)+++ src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java	(working copy)@@ -172,10 +172,10 @@ 			 			if ( at instanceof ArrayType ) 				return ((ArrayType)at).getElementType();-			else if ( at instanceof BottomType || at instanceof NullType )+			else if ( at instanceof BottomType || at instanceof NullType || at instanceof RefType ) 				return BottomType.v(); 			else throw new RuntimeException(-				"Base of array reference is not an array!");+				"Base of array reference is not an array! "+at); 		} 		else if ( expr instanceof NewArrayExpr ) 			return ((NewArrayExpr)expr).getBaseType().makeArrayType();@@ -225,4 +225,4 @@ 			return RefType.v("java.lang.Class"); 		else throw new RuntimeException("Unhandled expression: " + expr); 	}-}\ No newline at end of file+}Index: src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java===================================================================--- src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java	(revision 3600)+++ src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java	(working copy)@@ -227,15 +227,16 @@ 	Type baset = ((Local) ref.getBase()).getType(); 	if(!(baset instanceof NullType)) 	{-	  ArrayType base = (ArrayType) baset; 	  Value index = ref.getIndex();-	-	  if((base.numDimensions == 1) &&-	     (base.baseType instanceof IntegerType))-	    {-	      left = ClassHierarchy.v().typeNode(base.baseType);-	    }-	+	  if(baset instanceof ArrayType)+	  {+	    ArrayType base = (ArrayType) baset;+	    if((base.numDimensions == 1) &&+	       (base.baseType instanceof IntegerType))+	      {+	        left = ClassHierarchy.v().typeNode(base.baseType);+	      }+	  } 	  if(index instanceof Local) 	    { 	      if(!ClassHierarchy.v().typeNode(((Local) index).getType()).hasAncestor_1(ClassHierarchy.v().INT))@@ -290,15 +291,17 @@ 	Type baset = ((Local) ref.getBase()).getType(); 	if(!(baset instanceof NullType)) 	{-	  ArrayType base = (ArrayType) baset; 	  Value index = ref.getIndex();+	  if(baset instanceof ArrayType)+	  {+	    ArrayType base = (ArrayType) baset;+	    if((base.numDimensions == 1) &&+	       (base.baseType instanceof IntegerType))+	      {+	        right = ClassHierarchy.v().typeNode(base.baseType);+	      }+	  } 	-	  if((base.numDimensions == 1) &&-	     (base.baseType instanceof IntegerType))-	    {-	      right = ClassHierarchy.v().typeNode(base.baseType);-	    }-	 	  if(index instanceof Local) 	    { 	      if(!ClassHierarchy.v().typeNode(((Local) index).getType()).hasAncestor_1(ClassHierarchy.v().INT))Index: src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java===================================================================--- src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java	(revision 3600)+++ src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java	(working copy)@@ -168,15 +168,18 @@ 	Type baset = ((Local) ref.getBase()).getType(); 	if(!(baset instanceof NullType)) 	{-	  ArrayType base = (ArrayType) baset; 	  Value index = ref.getIndex(); 	 	  if(uses) 	    {-	      if((base.numDimensions == 1) &&-	         (base.baseType instanceof IntegerType))+	      if(baset instanceof ArrayType) 	        {-	  	  left = resolver.typeVariable(base.baseType);+		  ArrayType base = (ArrayType) baset;+	          if((base.numDimensions == 1) &&+	             (base.baseType instanceof IntegerType))+	            {+	  	      left = resolver.typeVariable(base.baseType);+	            } 	        } 	     	      if(index instanceof Local)@@ -234,15 +237,17 @@ 	Type baset = ((Local) ref.getBase()).getType(); 	if(!(baset instanceof NullType)) 	{-	  ArrayType base = (ArrayType) baset; 	  Value index = ref.getIndex();+	  if(baset instanceof ArrayType)+	  {+	    ArrayType base = (ArrayType) baset;+	    if((base.numDimensions == 1) &&+	       (base.baseType instanceof IntegerType))+	      {+	        right = resolver.typeVariable(base.baseType);+	      }+	  } 	-	  if((base.numDimensions == 1) &&-	     (base.baseType instanceof IntegerType))-	    {-	      right = resolver.typeVariable(base.baseType);-	    }-	 	  if(uses) 	    { 	      if(index instanceof Local)


P.S. THANK YOU VERY MUCH FOR AN EXCELLENT PRODUCT (especially one of this quality that is open source!), Kudos! 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111217/6fac235a/attachment.html 

From crysgirlro at yahoo.com  Sat Dec 17 06:15:32 2011
From: crysgirlro at yahoo.com (Cristina Ilie)
Date: Sat, 17 Dec 2011 03:15:32 -0800 (PST)
Subject: [Soot-list] Bug in dava phase or decompiling phase at a constant or
	buffer size
Message-ID: <1324120532.42691.YahooMailNeo@web161603.mail.bf1.yahoo.com>

Hello,

I found a new bug in soot,? I think it's something related to Dava phase or earlier to the decompiling phase. I discovered it because all it's ok 

when I run my tool (which extends soot) on expression like "double [] w = {1,2,3,4,5}" as long as the size of the array is smaller then 12... 

For these expressions my tool receives the Jimple code as "w[0] = 1; w[1] =2 ... " and for each assignment add a loop before it, a loop which
initializes something for its calculations. The idea is that all is ok until I introduce something with the size >= 12, like:
"double [] w = {1,2,3,4,5,6,7,8,9,10,11,12}". At this moment the last loop becomes an endlessness loop "while (true) ..." and it's impossible to 

obtain this kind of loop ...

Further I discovered that only when I'm trying to run "Dava Decompile App" on the following function [1], soot is not able to finish the 

transformation. It hangs up at "Analyzing C:\Users\Cris\work\AppSource\sootOutput\dava\src\AppSource.java... ", consuming 25% of my 

processor. Soot encounters this problem when I'm adding more than 10 elements to z (>=). For instance if I have the statement:? "z=w[0]+w[1]+w[2]+w[3]+w[4]+w[5]+w[6]+w[7]+w[8];" there is no problem.

I suppose the problem is related to a buffer size, a constant definition etc.


[1]

public static double compute (double x){
??? double z;
??? double w[] = new double[12];
??? z=w[0]+w[1]+w[2]+w[3]+w[4]+w[5]+w[6]+w[7]+w[8]+w[9];
??? return z;
}

Cristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111217/fd6c0482/attachment-0001.html 

From eric.bodden at ec-spride.de  Sat Dec 17 09:54:43 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Sat, 17 Dec 2011 15:54:43 +0100
Subject: [Soot-list] Some changes
In-Reply-To: <18589_1324106290_pBH7I8lq004769_COL113-W650C5C944A3ED1FDFB2080AFA10@phx.gbl>
References: <18589_1324106290_pBH7I8lq004769_COL113-W650C5C944A3ED1FDFB2080AFA10@phx.gbl>
Message-ID: <CALhVNNJsNHgwoyqkeDgq249ikeN4AXc31tsROxB2-rdoFEx5cQ@mail.gmail.com>

Hello.

Thanks for the patch but could you be a bit more specific? What
problem is this supposed to solve?

Cheers,
Eric

On 17 December 2011 08:12, Rule One <rule1_ at hotmail.com> wrote:
> I was having difficulties loading some classes using Soot, here are the
> changes I made to the source code (could someone verify if these are
> correct? I have absolutely no experience in Soot):
>
> Index: src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java
> ===================================================================
> --- src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java (revision
> 3600)
> +++ src/soot/jimple/toolkits/typing/fast/AugEvalFunction.java (working copy)
> @@ -172,10 +172,10 @@
>
> ? if ( at instanceof ArrayType )
> ? return ((ArrayType)at).getElementType();
> - else if ( at instanceof BottomType || at instanceof NullType )
> + else if ( at instanceof BottomType || at instanceof NullType || at
> instanceof RefType )
> ? return BottomType.v();
> ? else throw new RuntimeException(
> - "Base of array reference is not an array!");
> + "Base of array reference is not an array! "+at);
> ? }
> ? else if ( expr instanceof NewArrayExpr )
> ? return ((NewArrayExpr)expr).getBaseType().makeArrayType();
> @@ -225,4 +225,4 @@
> ? return RefType.v("java.lang.Class");
> ? else throw new RuntimeException("Unhandled expression: " + expr);
> ? }
> -}
> \ No newline at end of file
> +}
> Index: src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java
> ===================================================================
> --- src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java (revision
> 3600)
> +++ src/soot/jimple/toolkits/typing/integer/ConstraintChecker.java (working
> copy)
> @@ -227,15 +227,16 @@
> ? Type baset = ((Local) ref.getBase()).getType();
> ? if(!(baset instanceof NullType))
> ? {
> - ?ArrayType base = (ArrayType) baset;
> ? ?Value index = ref.getIndex();
> -
> - ?if((base.numDimensions == 1) &&
> - ? ? (base.baseType instanceof IntegerType))
> - ? ?{
> - ? ? ?left = ClassHierarchy.v().typeNode(base.baseType);
> - ? ?}
> -
> + ?if(baset instanceof ArrayType)
> + ?{
> + ? ?ArrayType base = (ArrayType) baset;
> + ? ?if((base.numDimensions == 1) &&
> + ? ? ? (base.baseType instanceof IntegerType))
> + ? ? ?{
> + ? ? ? ?left = ClassHierarchy.v().typeNode(base.baseType);
> + ? ? ?}
> + ?}
> ? ?if(index instanceof Local)
> ? ? ?{
> ? ? ? ?if(!ClassHierarchy.v().typeNode(((Local)
> index).getType()).hasAncestor_1(ClassHierarchy.v().INT))
> @@ -290,15 +291,17 @@
> ? Type baset = ((Local) ref.getBase()).getType();
> ? if(!(baset instanceof NullType))
> ? {
> - ?ArrayType base = (ArrayType) baset;
> ? ?Value index = ref.getIndex();
> + ?if(baset instanceof ArrayType)
> + ?{
> + ? ?ArrayType base = (ArrayType) baset;
> + ? ?if((base.numDimensions == 1) &&
> + ? ? ? (base.baseType instanceof IntegerType))
> + ? ? ?{
> + ? ? ? ?right = ClassHierarchy.v().typeNode(base.baseType);
> + ? ? ?}
> + ?}
>
> - ?if((base.numDimensions == 1) &&
> - ? ? (base.baseType instanceof IntegerType))
> - ? ?{
> - ? ? ?right = ClassHierarchy.v().typeNode(base.baseType);
> - ? ?}
> -
> ? ?if(index instanceof Local)
> ? ? ?{
> ? ? ? ?if(!ClassHierarchy.v().typeNode(((Local)
> index).getType()).hasAncestor_1(ClassHierarchy.v().INT))
> Index: src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java
> ===================================================================
> --- src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java
> (revision 3600)
> +++ src/soot/jimple/toolkits/typing/integer/ConstraintCollector.java
> (working copy)
> @@ -168,15 +168,18 @@
> ? Type baset = ((Local) ref.getBase()).getType();
> ? if(!(baset instanceof NullType))
> ? {
> - ?ArrayType base = (ArrayType) baset;
> ? ?Value index = ref.getIndex();
>
> ? ?if(uses)
> ? ? ?{
> - ? ? ?if((base.numDimensions == 1) &&
> - ? ? ? ? (base.baseType instanceof IntegerType))
> + ? ? ?if(baset instanceof ArrayType)
> ? ? ? ? ?{
> - ? ?left = resolver.typeVariable(base.baseType);
> + ?ArrayType base = (ArrayType) baset;
> + ? ? ? ? ?if((base.numDimensions == 1) &&
> + ? ? ? ? ? ? (base.baseType instanceof IntegerType))
> + ? ? ? ? ? ?{
> + ? ? ? ?left = resolver.typeVariable(base.baseType);
> + ? ? ? ? ? ?}
> ? ? ? ? ?}
>
> ? ? ? ?if(index instanceof Local)
> @@ -234,15 +237,17 @@
> ? Type baset = ((Local) ref.getBase()).getType();
> ? if(!(baset instanceof NullType))
> ? {
> - ?ArrayType base = (ArrayType) baset;
> ? ?Value index = ref.getIndex();
> + ?if(baset instanceof ArrayType)
> + ?{
> + ? ?ArrayType base = (ArrayType) baset;
> + ? ?if((base.numDimensions == 1) &&
> + ? ? ? (base.baseType instanceof IntegerType))
> + ? ? ?{
> + ? ? ? ?right = resolver.typeVariable(base.baseType);
> + ? ? ?}
> + ?}
>
> - ?if((base.numDimensions == 1) &&
> - ? ? (base.baseType instanceof IntegerType))
> - ? ?{
> - ? ? ?right = resolver.typeVariable(base.baseType);
> - ? ?}
> -
> ? ?if(uses)
> ? ? ?{
> ? ? ? ?if(index instanceof Local)
>
>
>
> P.S. THANK YOU VERY MUCH FOR AN EXCELLENT PRODUCT (especially one of this
> quality that is open source!), Kudos!
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From eric.bodden at ec-spride.de  Tue Dec 20 03:49:33 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Tue, 20 Dec 2011 09:49:33 +0100
Subject: [Soot-list] Call for Papers - SOAP 2012: 1st International Workshop
 on the State Of the Art in Java Program Analysis
In-Reply-To: <CALhVNNLA8kFpdQBHKEA7LxfY939pFx5WwkoBrGJgQE2p0FkbKQ@mail.gmail.com>
References: <CALhVNNLA8kFpdQBHKEA7LxfY939pFx5WwkoBrGJgQE2p0FkbKQ@mail.gmail.com>
Message-ID: <CALhVNNLev3s1+TO8jnWvqjXMBHg9zyPsVn_Hgjz6b+s7irFvCw@mail.gmail.com>

1st International Workshop on the State Of the Art in Java Program
Analysis (SOAP 2012)
Co-located with PLDI 2012, June 2012 in Beijing
http://www.sable.mcgill.ca/soap/


WORKSHOP TOPIC
Soot and other analysis frameworks have enabled hundreds of users to
carry out research in static analysis of Java. As Soot enters its
second decade, the first International Workshop on the State Of the
Art in Java Program Analysis (SOAP) will bring together the thriving
Soot community and help catalyze the future development of the Soot
framework. We anticipate that SOAP will help spur discussions and
collaborations between different groups using Soot and other compiler
frameworks. Although the focus of this workshop will be on the Soot
framework, we warmly welcome cross-pollination from other compilers
and analysis frameworks, for instance in the form of ideas and design
discussions. The agenda for SOAP will also include discussions and
work on integrating external contributions into the main Soot
framework, as well as explorations of potential future extensions to
Soot.


IMPORTANT DATES
Paper submissions: March 28th, 2012
Notification of authors: April 28th, 2012
Submission of camera-ready copies: ? ? ? May 12th, 2012
Workshop date: ? TBA (June 14th, 15th or 16th)

SUBMISSIONS
Submissions should be four to six-page papers in ACM sig-alternate
style. Some possible types of submissions for this workshop include,
but are not limited to:

* A report on an implementation of a static analysis, with a focus on
implementation details, particularly discussing how Soot or some other
static analysis framework was used.
* A report describing a tool built on top of Soot.
* A compelling use case for a feature not yet supported by the current
version of Soot. Such work should provide good examples and an
informal design of the proposed feature.
* An idea paper proposing the integration of two or more existing
static analyses (which may or may not be based on Soot) to answer
interesting novel questions about Java programs. Such papers should
focus on the added benefit obtained by the combinations. For this
category we explicitly encourage collaborative submissions by
different research groups.

Submissions must be handed in as PDF using EasyChair:
https://www.easychair.org/conferences/?conf=soap2012

PUBLICATION
Accepted publications will be published in the ACM Digital Library.

ORGANIZING COMMITTEE
Eric Bodden, Technische Universit?t Darmstadt
Laurie Hendren, McGill University
Patrick Lam, University of Waterloo
Elena Sherman, University of Nebraska

PROGRAM COMMITTEE
Eric Bodden, Technische Universit?t Darmstadt
Bruno Dufour, Universit? de Montr?al
Laurie Hendren, McGill University
Patrick Lam, University of Waterloo
Elena Sherman, University of Nebraska
Manu Sridharan, IBM Research

From plto001 at gmail.com  Tue Dec 20 04:21:35 2011
From: plto001 at gmail.com (Shim Gyuhang)
Date: Tue, 20 Dec 2011 18:21:35 +0900
Subject: [Soot-list] I got a heap memory error
Message-ID: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>

Hello.
My name is Gyuhang from Fasoo.com Inc.

We have been used soot framework for analyzing Java codes.
Yesterday, we have a Heap Memory Error from soot framework while analyzing Android source codes.

The stack trace is like below.

Soot has run out of the memory allocated to it by the Java VM.
To allocate more memory to Soot, use the -Xmx switch to Java.
For example (for 400MB): java -Xmx400m soot.Main ...
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.LinkedList.addBefore(LinkedList.java:778)
	at java.util.LinkedList.addLast(LinkedList.java:164)
	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
	at soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
	at soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
	at soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
	at soot.BodyTransformer.transform(BodyTransformer.java:51)
	at soot.Transform.apply(Transform.java:104)
	at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
	at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
	at soot.Pack.apply(Pack.java:124)
	at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
	at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
	at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
	at soot.PackManager.retrieveAllBodies(PackManager.java:989)
	at soot.PackManager.runPacks(PackManager.java:338)
	at soot.Main.run(Main.java:198)
	at soot.Main.main(Main.java:141)


The command line input for soot framework is like below. (I located the package to /tmp directory.)
java -Xmx2048m -jar sootclasses.jar -cp /tmp org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs

It will be very thankful, if you have me some advices.

The attached file below contains whole directory structure contains class file that causes Heap Memory Error.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.zip
Type: application/zip
Size: 5873 bytes
Desc: not available
Url : http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111220/39869ec6/attachment.zip 
-------------- next part --------------



--------------------------------------
Thanks. 
Life is good. All the time. :)

Fasoo.com Inc, PA dev team
Gyuhang Shim starblood at fasoo.com


From plto001 at gmail.com  Tue Dec 20 19:52:37 2011
From: plto001 at gmail.com (Shim Gyuhang)
Date: Wed, 21 Dec 2011 09:52:37 +0900
Subject: [Soot-list] I got a heap memory error
In-Reply-To: <COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
References: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>
	<COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
Message-ID: <6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>

I've tried the command from email you sent. But we still had the same error message from Soot framework.

For your reference, I ran the Visual VM to check what type of data is most used during execution.
As a result, about 1.5 GB of memory was assigned for HashMap. I assumed there is an infinite loop maybe?

Is there any solution?

--------------------------------------
Thanks. 
Life is good. All the time. :)

Fasoo.com Inc, PA dev team
Gyuhang Shim starblood at fasoo.com

Dec 21, 2011, 1:50 AM, Rule One ??:

> Try,
> java -Xms2048m -Xmx2048m -jar sootclasses.jar -cp /tmp org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
> 
> From: plto001 at gmail.com
> Date: Tue, 20 Dec 2011 18:21:35 +0900
> To: soot-list at sable.mcgill.ca
> CC: pa_dev at fasoo.com
> Subject: [Soot-list] I got a heap memory error
> 
> Hello.
> My name is Gyuhang from Fasoo.com Inc.
>  
> We have been used soot framework for analyzing Java codes.
> Yesterday, we have a Heap Memory Error from soot framework while analyzing Android source codes.
>  
> The stack trace is like below.
>  
> Soot has run out of the memory allocated to it by the Java VM.
> To allocate more memory to Soot, use the -Xmx switch to Java.
> For example (for 400MB): java -Xmx400m soot.Main ...
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> 	at java.util.LinkedList.addBefore(LinkedList.java:778)
> 	at java.util.LinkedList.addLast(LinkedList.java:164)
> 	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
> 	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
> 	at soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
> 	at soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
> 	at soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
> 	at soot.BodyTransformer.transform(BodyTransformer.java:51)
> 	at soot.Transform.apply(Transform.java:104)
> 	at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
> 	at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
> 	at soot.Pack.apply(Pack.java:124)
> 	at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
> 	at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
> 	at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
> 	at soot.PackManager.retrieveAllBodies(PackManager.java:989)
> 	at soot.PackManager.runPacks(PackManager.java:338)
> 	at soot.Main.run(Main.java:198)
> 	at soot.Main.main(Main.java:141)
>  
>  
> The command line input for soot framework is like below. (I located the package to /tmp directory.)
> java -Xmx2048m -jar sootclasses.jar -cp /tmp org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>  
> It will be very thankful, if you have me some advices.
>  
> The attached file below contains whole directory structure contains class file that causes Heap Memory Error.
>  
> 
> -------------------------------------- Thanks. Life is good. All the time. :) Fasoo.com Inc, PA dev team Gyuhang Shim starblood at fasoo.com
> _______________________________________________ Soot-list mailing list Soot-list at sable.mcgill.ca http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111221/fefa061b/attachment.html 

From eric.bodden at ec-spride.de  Wed Dec 21 07:41:09 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Wed, 21 Dec 2011 13:41:09 +0100
Subject: [Soot-list] I got a heap memory error
In-Reply-To: <6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>
References: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>
	<COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
	<6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>
Message-ID: <CALhVNNKg26igkkM_H5FW0xYocDOkUViWOAKc-dBd-tL9z_yvkQ@mail.gmail.com>

Hmm, indeed there appears to be an infinite loop in the worklist
algorithm of the type assigner.

Does this also happen when you do not use the phantom-refs option? The
use of phantom refs applies some tweaks to the type assigner, not all
of which may be correct.

Eric

2011/12/21 Shim Gyuhang <plto001 at gmail.com>:
> I've tried the command from email you sent. But we still had the same error
> message from Soot framework.
>
> For your reference, I ran the Visual VM to check what type of data is most
> used during execution.
> As a result, about 1.5 GB of memory was assigned for HashMap. I assumed
> there is an infinite loop maybe...
>
> Is there any solution?
>
> --------------------------------------
> Thanks.
> Life is good. All the time. :)
>
> Fasoo.com Inc, PA dev team
> Gyuhang Shim starblood at fasoo.com
>
> Dec 21, 2011, 1:50 AM, Rule One ??:
>
> Try,
>
> java -Xms2048m -Xmx2048m -jar sootclasses.jar -cp /tmp
> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>
>
> From: plto001 at gmail.com
> Date: Tue, 20 Dec 2011 18:21:35 +0900
> To: soot-list at sable.mcgill.ca
> CC: pa_dev at fasoo.com
> Subject: [Soot-list] I got a heap memory error
>
>
> Hello.
> My name is Gyuhang from Fasoo.com Inc.
>
> We have been used soot framework for analyzing Java codes.
> Yesterday, we have a Heap Memory Error from soot framework while analyzing
> Android source codes.
>
> The stack trace is like below.
>
> Soot has run out of the memory allocated to it by the Java VM.
> To allocate more memory to Soot, use the -Xmx switch to Java.
> For example (for 400MB): java -Xmx400m soot.Main ...
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> 	at java.util.LinkedList.addBefore(LinkedList.java:778)
> 	at java.util.LinkedList.addLast(LinkedList.java:164)
> 	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
> 	at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
> 	at
> soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
> 	at
> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
> 	at
> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
> 	at soot.BodyTransformer.transform(BodyTransformer.java:51)
> 	at soot.Transform.apply(Transform.java:104)
> 	at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
> 	at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
> 	at soot.Pack.apply(Pack.java:124)
> 	at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
> 	at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
> 	at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
> 	at soot.PackManager.retrieveAllBodies(PackManager.java:989)
> 	at soot.PackManager.runPacks(PackManager.java:338)
> 	at soot.Main.run(Main.java:198)
> 	at soot.Main.main(Main.java:141)
>
>
> The command line input for soot framework is like below. (I located the
> package to /tmp directory.)
> java -Xmx2048m -jar sootclasses.jar -cp /tmp
> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>
> It will be very thankful, if you have me some advices.
>
> The attached file below contains whole directory structure contains class
> file that causes Heap Memory Error.
>
>
>
> -------------------------------------- Thanks. Life is good. All the time.
> :) Fasoo.com Inc, PA dev team Gyuhang Shim starblood at fasoo.com
> _______________________________________________ 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
>



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422    Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From heejong at gmail.com  Thu Dec 22 01:03:27 2011
From: heejong at gmail.com (Heejong Lee)
Date: Thu, 22 Dec 2011 15:03:27 +0900
Subject: [Soot-list] I got a heap memory error
In-Reply-To: <CALhVNNKg26igkkM_H5FW0xYocDOkUViWOAKc-dBd-tL9z_yvkQ@mail.gmail.com>
References: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>
	<COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
	<6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>
	<CALhVNNKg26igkkM_H5FW0xYocDOkUViWOAKc-dBd-tL9z_yvkQ@mail.gmail.com>
Message-ID: <CAK3gJdEB3TZ8bhr4SP9Cw9g0GF6bDq14hyNx-4+xba2GC9t3AA@mail.gmail.com>

HI, Eric.

Unfortunately, we cannot remove -allow-phantom-refs option for now since
we do not have a complete list of dependencies.

After a brief investigation, I can confirm that there is an infinite
loop problem
in applyAssignmentConstraints(Typing, IEvalFunction, IHierarchy) method.
The variable LinkedList<Typing> sigma monotonically increases until the heap
memory overflow occurs. I diagramed the size fluctuation of sigma and figured
out that it looks virtually linear.

How do we guarantee that the sigma will be eventually empty? Is there any
bound condition for guaranteeing it?

Regards,

- Heejong Lee

On Wed, Dec 21, 2011 at 9:41 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> Hmm, indeed there appears to be an infinite loop in the worklist
> algorithm of the type assigner.
>
> Does this also happen when you do not use the phantom-refs option? The
> use of phantom refs applies some tweaks to the type assigner, not all
> of which may be correct.
>
> Eric
>
> 2011/12/21 Shim Gyuhang <plto001 at gmail.com>:
>> I've tried the command from email you sent. But we still had the same error
>> message from Soot framework.
>>
>> For your reference, I ran the Visual VM to check what type of data is most
>> used during execution.
>> As a result, about 1.5 GB of memory was assigned for HashMap. I assumed
>> there is an infinite loop maybe...
>>
>> Is there any solution?
>>
>> --------------------------------------
>> Thanks.
>> Life is good. All the time. :)
>>
>> Fasoo.com Inc, PA dev team
>> Gyuhang Shim starblood at fasoo.com
>>
>> Dec 21, 2011, 1:50 AM, Rule One ??:
>>
>> Try,
>>
>> java -Xms2048m -Xmx2048m -jar sootclasses.jar -cp /tmp
>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>
>>
>> From: plto001 at gmail.com
>> Date: Tue, 20 Dec 2011 18:21:35 +0900
>> To: soot-list at sable.mcgill.ca
>> CC: pa_dev at fasoo.com
>> Subject: [Soot-list] I got a heap memory error
>>
>>
>> Hello.
>> My name is Gyuhang from Fasoo.com Inc.
>>
>> We have been used soot framework for analyzing Java codes.
>> Yesterday, we have a Heap Memory Error from soot framework while analyzing
>> Android source codes.
>>
>> The stack trace is like below.
>>
>> Soot has run out of the memory allocated to it by the Java VM.
>> To allocate more memory to Soot, use the -Xmx switch to Java.
>> For example (for 400MB): java -Xmx400m soot.Main ...
>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>> ? ? ? at java.util.LinkedList.addBefore(LinkedList.java:778)
>> ? ? ? at java.util.LinkedList.addLast(LinkedList.java:164)
>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
>> ? ? ? at
>> soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
>> ? ? ? at
>> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
>> ? ? ? at
>> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
>> ? ? ? at soot.BodyTransformer.transform(BodyTransformer.java:51)
>> ? ? ? at soot.Transform.apply(Transform.java:104)
>> ? ? ? at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
>> ? ? ? at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
>> ? ? ? at soot.Pack.apply(Pack.java:124)
>> ? ? ? at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
>> ? ? ? at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
>> ? ? ? at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
>> ? ? ? at soot.PackManager.retrieveAllBodies(PackManager.java:989)
>> ? ? ? at soot.PackManager.runPacks(PackManager.java:338)
>> ? ? ? at soot.Main.run(Main.java:198)
>> ? ? ? at soot.Main.main(Main.java:141)
>>
>>
>> The command line input for soot framework is like below. (I located the
>> package to /tmp directory.)
>> java -Xmx2048m -jar sootclasses.jar -cp /tmp
>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>
>> It will be very thankful, if you have me some advices.
>>
>> The attached file below contains whole directory structure contains class
>> file that causes Heap Memory Error.
>>
>>
>>
>> -------------------------------------- Thanks. Life is good. All the time.
>> :) Fasoo.com Inc, PA dev team Gyuhang Shim starblood at fasoo.com
>> _______________________________________________ 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
>>
>
>
>
> --
> Eric Bodden, Ph.D., http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Principal Investigator in Secure Services at CASED
> Tel: +49 6151 16-75422 ? ?Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list



-- 
Heejong Lee

Associate Research Engineer
Program Analysis Division
Fasoo.com, Inc. (www.spa-arrow.com)

From eric.bodden at ec-spride.de  Thu Dec 22 03:26:18 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 22 Dec 2011 09:26:18 +0100
Subject: [Soot-list] I got a heap memory error
In-Reply-To: <CAK3gJdEB3TZ8bhr4SP9Cw9g0GF6bDq14hyNx-4+xba2GC9t3AA@mail.gmail.com>
References: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>
	<COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
	<6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>
	<CALhVNNKg26igkkM_H5FW0xYocDOkUViWOAKc-dBd-tL9z_yvkQ@mail.gmail.com>
	<CAK3gJdEB3TZ8bhr4SP9Cw9g0GF6bDq14hyNx-4+xba2GC9t3AA@mail.gmail.com>
Message-ID: <CALhVNN+ZAEtrs4S38TnK60O+n5DH96aswho33ZYHiK6+vTSJJg@mail.gmail.com>

I have emailed Ben Bellamy who contributed that code. Hopefully he
will find some time to give us some advice. May not happen over the
holidays, though...

Cheers,
Eric

On 22 December 2011 07:03, Heejong Lee <heejong at gmail.com> wrote:
> HI, Eric.
>
> Unfortunately, we cannot remove -allow-phantom-refs option for now since
> we do not have a complete list of dependencies.
>
> After a brief investigation, I can confirm that there is an infinite
> loop problem
> in applyAssignmentConstraints(Typing, IEvalFunction, IHierarchy) method.
> The variable LinkedList<Typing> sigma monotonically increases until the heap
> memory overflow occurs. I diagramed the size fluctuation of sigma and figured
> out that it looks virtually linear.
>
> How do we guarantee that the sigma will be eventually empty? Is there any
> bound condition for guaranteeing it?
>
> Regards,
>
> - Heejong Lee
>
> On Wed, Dec 21, 2011 at 9:41 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>> Hmm, indeed there appears to be an infinite loop in the worklist
>> algorithm of the type assigner.
>>
>> Does this also happen when you do not use the phantom-refs option? The
>> use of phantom refs applies some tweaks to the type assigner, not all
>> of which may be correct.
>>
>> Eric
>>
>> 2011/12/21 Shim Gyuhang <plto001 at gmail.com>:
>>> I've tried the command from email you sent. But we still had the same error
>>> message from Soot framework.
>>>
>>> For your reference, I ran the Visual VM to check what type of data is most
>>> used during execution.
>>> As a result, about 1.5 GB of memory was assigned for HashMap. I assumed
>>> there is an infinite loop maybe...
>>>
>>> Is there any solution?
>>>
>>> --------------------------------------
>>> Thanks.
>>> Life is good. All the time. :)
>>>
>>> Fasoo.com Inc, PA dev team
>>> Gyuhang Shim starblood at fasoo.com
>>>
>>> Dec 21, 2011, 1:50 AM, Rule One ??:
>>>
>>> Try,
>>>
>>> java -Xms2048m -Xmx2048m -jar sootclasses.jar -cp /tmp
>>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>>
>>>
>>> From: plto001 at gmail.com
>>> Date: Tue, 20 Dec 2011 18:21:35 +0900
>>> To: soot-list at sable.mcgill.ca
>>> CC: pa_dev at fasoo.com
>>> Subject: [Soot-list] I got a heap memory error
>>>
>>>
>>> Hello.
>>> My name is Gyuhang from Fasoo.com Inc.
>>>
>>> We have been used soot framework for analyzing Java codes.
>>> Yesterday, we have a Heap Memory Error from soot framework while analyzing
>>> Android source codes.
>>>
>>> The stack trace is like below.
>>>
>>> Soot has run out of the memory allocated to it by the Java VM.
>>> To allocate more memory to Soot, use the -Xmx switch to Java.
>>> For example (for 400MB): java -Xmx400m soot.Main ...
>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>> ? ? ? at java.util.LinkedList.addBefore(LinkedList.java:778)
>>> ? ? ? at java.util.LinkedList.addLast(LinkedList.java:164)
>>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
>>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
>>> ? ? ? at
>>> soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
>>> ? ? ? at
>>> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
>>> ? ? ? at
>>> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
>>> ? ? ? at soot.BodyTransformer.transform(BodyTransformer.java:51)
>>> ? ? ? at soot.Transform.apply(Transform.java:104)
>>> ? ? ? at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
>>> ? ? ? at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
>>> ? ? ? at soot.Pack.apply(Pack.java:124)
>>> ? ? ? at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
>>> ? ? ? at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
>>> ? ? ? at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
>>> ? ? ? at soot.PackManager.retrieveAllBodies(PackManager.java:989)
>>> ? ? ? at soot.PackManager.runPacks(PackManager.java:338)
>>> ? ? ? at soot.Main.run(Main.java:198)
>>> ? ? ? at soot.Main.main(Main.java:141)
>>>
>>>
>>> The command line input for soot framework is like below. (I located the
>>> package to /tmp directory.)
>>> java -Xmx2048m -jar sootclasses.jar -cp /tmp
>>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>>
>>> It will be very thankful, if you have me some advices.
>>>
>>> The attached file below contains whole directory structure contains class
>>> file that causes Heap Memory Error.
>>>
>>>
>>>
>>> -------------------------------------- Thanks. Life is good. All the time.
>>> :) Fasoo.com Inc, PA dev team Gyuhang Shim starblood at fasoo.com
>>> _______________________________________________ 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
>>>
>>
>>
>>
>> --
>> Eric Bodden, Ph.D., http://bodden.de/
>> Head of Secure Software Engineering Group at EC SPRIDE
>> Principal Investigator in Secure Services at CASED
>> Tel: +49 6151 16-75422 ? ?Fax: +49 6151 16-72051
>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>> _______________________________________________
>> Soot-list mailing list
>> Soot-list at sable.mcgill.ca
>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
>
> --
> Heejong Lee
>
> Associate Research Engineer
> Program Analysis Division
> Fasoo.com, Inc. (www.spa-arrow.com)



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From prashant.deva at gmail.com  Mon Dec 26 19:43:45 2011
From: prashant.deva at gmail.com (Prashant Deva)
Date: Mon, 26 Dec 2011 16:43:45 -0800
Subject: [Soot-list] Does soot support java 7?
Message-ID: <CAEg0NFbj=40Nkou+FCqivaB6_U5Nigf8m8zkK4vXUgYcsW1Z5w@mail.gmail.com>

Does soot/jimple support java 7 class file format?
If not, is there a timeline for the support to be added?

Prashant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111226/be6bcd99/attachment.html 

From eric.bodden at ec-spride.de  Tue Dec 27 08:25:13 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Tue, 27 Dec 2011 14:25:13 +0100
Subject: [Soot-list] Does soot support java 7?
In-Reply-To: <CAEg0NFbj=40Nkou+FCqivaB6_U5Nigf8m8zkK4vXUgYcsW1Z5w@mail.gmail.com>
References: <CAEg0NFbj=40Nkou+FCqivaB6_U5Nigf8m8zkK4vXUgYcsW1Z5w@mail.gmail.com>
Message-ID: <CALhVNNJ1zZ9tLO64HqFRu4Vk+3H8fSUMCnzLY1qXEava=rs3-g@mail.gmail.com>

Hi Prashant.

I had some student implement Java 7 support, i.e., support for the
invokedynamic bytecode. Unfortunately, we did this based on a beta
version of the Java 7 JDK and hence the support is currently broken
because for some reason Sun/Oracle changed the design slightly at the
last minute.

Having said that, the support should still be virtually complete. The
only things that changed (and hence are currently broken) is the
conversion from bytecode to Baf, and from Jasmin back to bytecode.
Hence I guess this could easily be fixed if someone volunteered to
spend a couple of hours on this.

Another problem I recently hit is to actually get my hands on Java 7
bytecode that contains invokedynamic bytecodes. In the beta version
there was a special version of the javac compiler that would turn
method calls on the class "Invoke" automatically into invokedynamic
bytecodes. With the release version of Java 7, however, this
functionality seems to have disappeared. This, in turn, makes it hard
to test our current implementation. Any suggestions on this would be
greatly appreciated.

Eric

On 27 December 2011 01:43, Prashant Deva <prashant.deva at gmail.com> wrote:
> Does soot/jimple support java 7 class file format?
> If not, is there a timeline for the support to be added?
>
> Prashant
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From prashant.deva at gmail.com  Tue Dec 27 18:33:42 2011
From: prashant.deva at gmail.com (Prashant Deva)
Date: Tue, 27 Dec 2011 15:33:42 -0800
Subject: [Soot-list] Using soot within a javaagent
Message-ID: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>

All the examples/tutorials I see of soot show it being used as a command
line tool.

Is it possible to use it as part of a javaagent to analyse classes
individually as they are loaded?

In this case the only input available to soot would be the byte array of
the class being loaded at the moment.
Not that since the class would not have been loaded at this point, if soot
tries to use .class methods on the class being analyzed, those will throw
an exception.

Prashant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111227/f4a50c38/attachment.html 

From eric.bodden at ec-spride.de  Thu Dec 29 09:26:31 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Thu, 29 Dec 2011 15:26:31 +0100
Subject: [Soot-list] Using soot within a javaagent
In-Reply-To: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>
References: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>
Message-ID: <CALhVNN+JOjzisThD08JUyrgvqU8hNh9spoXhuGATeRJo6uTugQ@mail.gmail.com>

Hello Prashant.

On 28 December 2011 00:33, Prashant Deva <prashant.deva at gmail.com> wrote:
> All the examples/tutorials I see of soot show it being used as a command
> line tool.
>
> Is it possible to use it as part of a javaagent to analyse classes
> individually as they are loaded?

That's an interesting question. Indeed this would be very helpful.
Soot is not currently set up to do this and it would require some
restructuring to make this work. The problem ist that when Soot loads
a class, transforming it into Jimple, at the same time it tries to
resolve (and therefore load) referenced classes up to a certain
amount. This is somewhat different from the class-loading process as
it happens in the JVM. I am reasonably sure Soot could be restructured
to make this work, and it would indeed be great to see this work, but
I have never tried, nor do I know of anyone else who has.

> In this case the only input available to soot would be the byte array of the
> class being loaded at the moment.
> Not that since the class would not have been loaded at this point, if soot
> tries to use .class methods on the class being analyzed, those will throw an
> exception.

That's not an issue. Soot does not really need anything else but the
byte array. The problem is rather in the resolution of dependencies,
as mentioned above. If you were to give this a try I would be happy to
assist you!

Best wishes,
Eric

From prashant.deva at gmail.com  Thu Dec 29 20:50:14 2011
From: prashant.deva at gmail.com (Prashant Deva)
Date: Thu, 29 Dec 2011 17:50:14 -0800
Subject: [Soot-list] Using soot within a javaagent
In-Reply-To: <CALhVNN+JOjzisThD08JUyrgvqU8hNh9spoXhuGATeRJo6uTugQ@mail.gmail.com>
References: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>
	<CALhVNN+JOjzisThD08JUyrgvqU8hNh9spoXhuGATeRJo6uTugQ@mail.gmail.com>
Message-ID: <CAEg0NFYyBMPHzNZOiaGdoPkaP_ryFVQQvq8q2zHZZqyr9u_O=w@mail.gmail.com>

Hi Eric,
 Yes, I would very much like to work with you on restructuring soot to
allow it to work as a javaagent.

As for resolution of dependencies, I dont require it and i guess anyone
using it as a java agent wont either.

I personally am trying to get only intra procedural alias analysis
information.
If i am correct, this would require converting the bytecode to jimple and
for each method separately getting the 'points-to' data.

Any guidance on where to start restructing the codebase to achieve the
required and get rid of dependency resolution would be helpful and as per
the terms of lgpl i would be happy to share my results with you.



Prashant


On Thu, Dec 29, 2011 at 6:26 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:

> Hello Prashant.
>
> On 28 December 2011 00:33, Prashant Deva <prashant.deva at gmail.com> wrote:
> > All the examples/tutorials I see of soot show it being used as a command
> > line tool.
> >
> > Is it possible to use it as part of a javaagent to analyse classes
> > individually as they are loaded?
>
> That's an interesting question. Indeed this would be very helpful.
> Soot is not currently set up to do this and it would require some
> restructuring to make this work. The problem ist that when Soot loads
> a class, transforming it into Jimple, at the same time it tries to
> resolve (and therefore load) referenced classes up to a certain
> amount. This is somewhat different from the class-loading process as
> it happens in the JVM. I am reasonably sure Soot could be restructured
> to make this work, and it would indeed be great to see this work, but
> I have never tried, nor do I know of anyone else who has.
>
> > In this case the only input available to soot would be the byte array of
> the
> > class being loaded at the moment.
> > Not that since the class would not have been loaded at this point, if
> soot
> > tries to use .class methods on the class being analyzed, those will
> throw an
> > exception.
>
> That's not an issue. Soot does not really need anything else but the
> byte array. The problem is rather in the resolution of dependencies,
> as mentioned above. If you were to give this a try I would be happy to
> assist you!
>
> Best wishes,
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111229/468b714c/attachment.html 

From eric.bodden at ec-spride.de  Fri Dec 30 05:31:09 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 30 Dec 2011 11:31:09 +0100
Subject: [Soot-list] Using soot within a javaagent
In-Reply-To: <CAEg0NFYyBMPHzNZOiaGdoPkaP_ryFVQQvq8q2zHZZqyr9u_O=w@mail.gmail.com>
References: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>
	<CALhVNN+JOjzisThD08JUyrgvqU8hNh9spoXhuGATeRJo6uTugQ@mail.gmail.com>
	<CAEg0NFYyBMPHzNZOiaGdoPkaP_ryFVQQvq8q2zHZZqyr9u_O=w@mail.gmail.com>
Message-ID: <CALhVNNJgsZ1SryEhdYBKUhFgp8A7aTuPOS1cXoGtXzp38iQ7CA@mail.gmail.com>

Hello.

> ?Yes, I would very much like to work with you on restructuring soot to allow
> it to work as a javaagent.

Great. Then let's discuss what needs to be done.

> As for resolution of dependencies, I dont require it and i guess anyone
> using it as a java agent wont either.

Things are not quite that simple. Soot uses some amount of typing
information (and in particular the type hierarchy) to re-construct
typed local variables from (untyped) stack locations. Hence, Soot
usually does need some knowledge about the dependencies. Having said
that, Soot's phantom-refs mechanism usually allows one to model
dependencies as "empty phantom classes", which is often good enough.
Those phantom classes do not carry any information about the actual
type hierarchy but for things like local pointer analysis that may not
actually matter.

In a first step, you should probably try for a few example classes if
Soot emits "reasonable" Jimple code when invoked on a simple class
with phantom refs enabled, e.g.:

soot -f J -cp . -allow-phantom-refs TestClass

(where the current directory only contains TestClass.class/.java and
nothing else)

> If i am correct, this would require converting the bytecode to jimple and
> for each method separately getting the 'points-to' data.

The points-to analysis does not really work on an intra-procedural
level but there are a LocalMustAliasAnalysis and
LocalMustNotAliasAnalysis that should do the trick.

> Any guidance on where to start restructing the codebase to achieve the
> required and get rid of dependency resolution would be helpful and as per
> the terms of lgpl i would be happy to share my results with you.

Ok, assuming that the bytecode-to-Jimple conversion generally works
reasonably correct on a single class (see above), I think one would
then need to proceed as follows:

Soot currently loads classes by name: you provide a name and Soot
looks for that class on its classpath. Lookup is performed by passing
the class name to soot.SourceLocator.getClassSource(String), which
returns a classSource, i.e., an actual input stream from which the raw
bytecode (or source code) can be read.

This mechanism would need to be gone around for the proposed
"classloader plugin". Instead one would need to pass a raw byte array
to Soot, and Soot would then need to discover the class name from that
bytecode. The actual conversion from bytecode to Jimple happens in
soot.coffi.Util.resolveFromClassFile(SootClass, InputStream, List), if
I am not mistaken. This method could be used to convert the incoming
byte array (via a ByteArrayInputStream) to a SootClass. Also,
Options.v().set_allow_phantom_refs(true) must be called to enable
phantom refs.

I would recommend to not tamper with Soot's existing main method, and
leave the mechanism there intact. Instead I would recommend to
actually define a new ClassFileTransformer that invokes the components
mentioned above correctly.

That's a rough outline of what would need to be done (I think). Let me
know whether this is helpful to you.

Eric

From eric.bodden at ec-spride.de  Fri Dec 30 05:36:38 2011
From: eric.bodden at ec-spride.de (Eric Bodden)
Date: Fri, 30 Dec 2011 11:36:38 +0100
Subject: [Soot-list] I got a heap memory error
In-Reply-To: <CALhVNN+ZAEtrs4S38TnK60O+n5DH96aswho33ZYHiK6+vTSJJg@mail.gmail.com>
References: <56004000-1AA7-4AA3-A338-125DE608C218@gmail.com>
	<COL113-W459E59626C5AB50DFE038DAFA40@phx.gbl>
	<6FBD8E22-B9FA-4235-9552-B17AB6F86130@gmail.com>
	<CALhVNNKg26igkkM_H5FW0xYocDOkUViWOAKc-dBd-tL9z_yvkQ@mail.gmail.com>
	<CAK3gJdEB3TZ8bhr4SP9Cw9g0GF6bDq14hyNx-4+xba2GC9t3AA@mail.gmail.com>
	<CALhVNN+ZAEtrs4S38TnK60O+n5DH96aswho33ZYHiK6+vTSJJg@mail.gmail.com>
Message-ID: <CALhVNN+fWauQTFW-t8w3RS55iWSLcDjr6G4s1nb2v3nQ9eEi1w@mail.gmail.com>

Hi Shim.

Ben Bellamy was so nice to look into this issue. The problem
originates from the lack of a complete type hierarchy when there is no
JDK on Soot's classpath. We are still looking into how to best fix
this issue. Having said this, a simple workaround for you may be to
just include "rt.jar" from the JDK on Soot's classpath. Can you try
this?

Eric

On 22 December 2011 09:26, Eric Bodden <eric.bodden at ec-spride.de> wrote:
> I have emailed Ben Bellamy who contributed that code. Hopefully he
> will find some time to give us some advice. May not happen over the
> holidays, though...
>
> Cheers,
> Eric
>
> On 22 December 2011 07:03, Heejong Lee <heejong at gmail.com> wrote:
>> HI, Eric.
>>
>> Unfortunately, we cannot remove -allow-phantom-refs option for now since
>> we do not have a complete list of dependencies.
>>
>> After a brief investigation, I can confirm that there is an infinite
>> loop problem
>> in applyAssignmentConstraints(Typing, IEvalFunction, IHierarchy) method.
>> The variable LinkedList<Typing> sigma monotonically increases until the heap
>> memory overflow occurs. I diagramed the size fluctuation of sigma and figured
>> out that it looks virtually linear.
>>
>> How do we guarantee that the sigma will be eventually empty? Is there any
>> bound condition for guaranteeing it?
>>
>> Regards,
>>
>> - Heejong Lee
>>
>> On Wed, Dec 21, 2011 at 9:41 PM, Eric Bodden <eric.bodden at ec-spride.de> wrote:
>>> Hmm, indeed there appears to be an infinite loop in the worklist
>>> algorithm of the type assigner.
>>>
>>> Does this also happen when you do not use the phantom-refs option? The
>>> use of phantom refs applies some tweaks to the type assigner, not all
>>> of which may be correct.
>>>
>>> Eric
>>>
>>> 2011/12/21 Shim Gyuhang <plto001 at gmail.com>:
>>>> I've tried the command from email you sent. But we still had the same error
>>>> message from Soot framework.
>>>>
>>>> For your reference, I ran the Visual VM to check what type of data is most
>>>> used during execution.
>>>> As a result, about 1.5 GB of memory was assigned for HashMap. I assumed
>>>> there is an infinite loop maybe...
>>>>
>>>> Is there any solution?
>>>>
>>>> --------------------------------------
>>>> Thanks.
>>>> Life is good. All the time. :)
>>>>
>>>> Fasoo.com Inc, PA dev team
>>>> Gyuhang Shim starblood at fasoo.com
>>>>
>>>> Dec 21, 2011, 1:50 AM, Rule One ??:
>>>>
>>>> Try,
>>>>
>>>> java -Xms2048m -Xmx2048m -jar sootclasses.jar -cp /tmp
>>>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>>>
>>>>
>>>> From: plto001 at gmail.com
>>>> Date: Tue, 20 Dec 2011 18:21:35 +0900
>>>> To: soot-list at sable.mcgill.ca
>>>> CC: pa_dev at fasoo.com
>>>> Subject: [Soot-list] I got a heap memory error
>>>>
>>>>
>>>> Hello.
>>>> My name is Gyuhang from Fasoo.com Inc.
>>>>
>>>> We have been used soot framework for analyzing Java codes.
>>>> Yesterday, we have a Heap Memory Error from soot framework while analyzing
>>>> Android source codes.
>>>>
>>>> The stack trace is like below.
>>>>
>>>> Soot has run out of the memory allocated to it by the Java VM.
>>>> To allocate more memory to Soot, use the -Xmx switch to Java.
>>>> For example (for 400MB): java -Xmx400m soot.Main ...
>>>> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>>>> ? ? ? at java.util.LinkedList.addBefore(LinkedList.java:778)
>>>> ? ? ? at java.util.LinkedList.addLast(LinkedList.java:164)
>>>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:64)
>>>> ? ? ? at soot.jimple.toolkits.typing.fast.QueuedSet.addLast(QueuedSet.java:74)
>>>> ? ? ? at
>>>> soot.jimple.toolkits.typing.fast.TypeResolver.applyAssignmentConstraints(TypeResolver.java:450)
>>>> ? ? ? at
>>>> soot.jimple.toolkits.typing.fast.TypeResolver.inferTypes(TypeResolver.java:113)
>>>> ? ? ? at
>>>> soot.jimple.toolkits.typing.TypeAssigner.internalTransform(TypeAssigner.java:101)
>>>> ? ? ? at soot.BodyTransformer.transform(BodyTransformer.java:51)
>>>> ? ? ? at soot.Transform.apply(Transform.java:104)
>>>> ? ? ? at soot.JimpleBodyPack.applyPhaseOptions(JimpleBodyPack.java:66)
>>>> ? ? ? at soot.JimpleBodyPack.internalApply(JimpleBodyPack.java:89)
>>>> ? ? ? at soot.Pack.apply(Pack.java:124)
>>>> ? ? ? at soot.coffi.CoffiMethodSource.getBody(CoffiMethodSource.java:117)
>>>> ? ? ? at soot.SootMethod.getBodyFromMethodSource(SootMethod.java:82)
>>>> ? ? ? at soot.SootMethod.retrieveActiveBody(SootMethod.java:315)
>>>> ? ? ? at soot.PackManager.retrieveAllBodies(PackManager.java:989)
>>>> ? ? ? at soot.PackManager.runPacks(PackManager.java:338)
>>>> ? ? ? at soot.Main.run(Main.java:198)
>>>> ? ? ? at soot.Main.main(Main.java:141)
>>>>
>>>>
>>>> The command line input for soot framework is like below. (I located the
>>>> package to /tmp directory.)
>>>> java -Xmx2048m -jar sootclasses.jar -cp /tmp
>>>> org.apache.harmony.luni.tests.java.util.Arrays2Test -allow-phantom-refs
>>>>
>>>> It will be very thankful, if you have me some advices.
>>>>
>>>> The attached file below contains whole directory structure contains class
>>>> file that causes Heap Memory Error.
>>>>
>>>>
>>>>
>>>> -------------------------------------- Thanks. Life is good. All the time.
>>>> :) Fasoo.com Inc, PA dev team Gyuhang Shim starblood at fasoo.com
>>>> _______________________________________________ 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
>>>>
>>>
>>>
>>>
>>> --
>>> Eric Bodden, Ph.D., http://bodden.de/
>>> Head of Secure Software Engineering Group at EC SPRIDE
>>> Principal Investigator in Secure Services at CASED
>>> Tel: +49 6151 16-75422 ? ?Fax: +49 6151 16-72051
>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>>> _______________________________________________
>>> Soot-list mailing list
>>> Soot-list at sable.mcgill.ca
>>> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>>
>>
>>
>> --
>> Heejong Lee
>>
>> Associate Research Engineer
>> Program Analysis Division
>> Fasoo.com, Inc. (www.spa-arrow.com)
>
>
>
> --
> Eric Bodden, Ph.D., http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Principal Investigator in Secure Services at CASED
> Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt



-- 
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422? ? Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt

From rule1_ at hotmail.com  Fri Dec 30 14:58:45 2011
From: rule1_ at hotmail.com (Rule One)
Date: Fri, 30 Dec 2011 13:58:45 -0600
Subject: [Soot-list] AbstractIntLongBinopExpr types
Message-ID: <COL113-W38051BB4DF0057F4B86273AF920@phx.gbl>


In AbstractIntLongBinopExpr (and also the float variant) the getType has,        Value op1 = op1Box.getValue();        Value op2 = op1Box.getValue();
Is this correct? Using the op 1 box's value for op2? 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111230/fc8124d4/attachment.html 

From prashant.deva at gmail.com  Sat Dec 31 02:58:41 2011
From: prashant.deva at gmail.com (Prashant Deva)
Date: Fri, 30 Dec 2011 23:58:41 -0800
Subject: [Soot-list] Using soot within a javaagent
In-Reply-To: <CALhVNNJgsZ1SryEhdYBKUhFgp8A7aTuPOS1cXoGtXzp38iQ7CA@mail.gmail.com>
References: <CAEg0NFaVpYymuvkPzxPMY-iKfv6XPuHa3A8cPS=+=SgnPvRaZw@mail.gmail.com>
	<CALhVNN+JOjzisThD08JUyrgvqU8hNh9spoXhuGATeRJo6uTugQ@mail.gmail.com>
	<CAEg0NFYyBMPHzNZOiaGdoPkaP_ryFVQQvq8q2zHZZqyr9u_O=w@mail.gmail.com>
	<CALhVNNJgsZ1SryEhdYBKUhFgp8A7aTuPOS1cXoGtXzp38iQ7CA@mail.gmail.com>
Message-ID: <CAEg0NFbrsKk17E5DZPC8ONrF16EQrQQL91NVdQ3XRjEBJ+_5SQ@mail.gmail.com>

Ok, so result of my little experiment:

This code:

public static void main(String[] args)
{
Options.v().allow_phantom_refs();
SootClass sootClass = Scene.v().loadClass("com.chtest.Snippet",
SootClass.BODIES);

}

throws an exception:
java.lang.IllegalStateException: RefType java.lang.ArithmeticException not
loaded.

if i add the line:
Scene.v().loadNecessaryClasses();

then the exception is gone.

Here is the Snippet class:
public class Snippet
{
public int foo(int i, int j) {
    while (true) {
        try {
            while (i < j)
                i = j++ / i;
        } catch (RuntimeException re) {
            i = 10;
            continue;
        }
        break;
    }
    return j;
}
 }

Why is it that even after allowing phantom refs soot throws an exception
for a type not loaded?


Prashant


On Fri, Dec 30, 2011 at 2:31 AM, Eric Bodden <eric.bodden at ec-spride.de>wrote:

> Hello.
>
> >  Yes, I would very much like to work with you on restructuring soot to
> allow
> > it to work as a javaagent.
>
> Great. Then let's discuss what needs to be done.
>
> > As for resolution of dependencies, I dont require it and i guess anyone
> > using it as a java agent wont either.
>
> Things are not quite that simple. Soot uses some amount of typing
> information (and in particular the type hierarchy) to re-construct
> typed local variables from (untyped) stack locations. Hence, Soot
> usually does need some knowledge about the dependencies. Having said
> that, Soot's phantom-refs mechanism usually allows one to model
> dependencies as "empty phantom classes", which is often good enough.
> Those phantom classes do not carry any information about the actual
> type hierarchy but for things like local pointer analysis that may not
> actually matter.
>
> In a first step, you should probably try for a few example classes if
> Soot emits "reasonable" Jimple code when invoked on a simple class
> with phantom refs enabled, e.g.:
>
> soot -f J -cp . -allow-phantom-refs TestClass
>
> (where the current directory only contains TestClass.class/.java and
> nothing else)
>
> > If i am correct, this would require converting the bytecode to jimple and
> > for each method separately getting the 'points-to' data.
>
> The points-to analysis does not really work on an intra-procedural
> level but there are a LocalMustAliasAnalysis and
> LocalMustNotAliasAnalysis that should do the trick.
>
> > Any guidance on where to start restructing the codebase to achieve the
> > required and get rid of dependency resolution would be helpful and as per
> > the terms of lgpl i would be happy to share my results with you.
>
> Ok, assuming that the bytecode-to-Jimple conversion generally works
> reasonably correct on a single class (see above), I think one would
> then need to proceed as follows:
>
> Soot currently loads classes by name: you provide a name and Soot
> looks for that class on its classpath. Lookup is performed by passing
> the class name to soot.SourceLocator.getClassSource(String), which
> returns a classSource, i.e., an actual input stream from which the raw
> bytecode (or source code) can be read.
>
> This mechanism would need to be gone around for the proposed
> "classloader plugin". Instead one would need to pass a raw byte array
> to Soot, and Soot would then need to discover the class name from that
> bytecode. The actual conversion from bytecode to Jimple happens in
> soot.coffi.Util.resolveFromClassFile(SootClass, InputStream, List), if
> I am not mistaken. This method could be used to convert the incoming
> byte array (via a ByteArrayInputStream) to a SootClass. Also,
> Options.v().set_allow_phantom_refs(true) must be called to enable
> phantom refs.
>
> I would recommend to not tamper with Soot's existing main method, and
> leave the mechanism there intact. Instead I would recommend to
> actually define a new ClassFileTransformer that invokes the components
> mentioned above correctly.
>
> That's a rough outline of what would need to be done (I think). Let me
> know whether this is helpful to you.
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20111230/3741d4f7/attachment.html 

