Merge pull request #33 from malaverdiere/develop

Fix for issue #32
Identation fixes.
StronglyConnectedComponentsFast accepts multi-headed directed graph.
Merge pull request #34 from quentin/feature-multiheads-scc

Feature multiheads scc
made a few modifications to the type assigner, avoiding ClassCastExceptions;

as Damien Octeau writes:

"I found a couple more places in Soot where there were some issues:

In soot/FastHierarchy.java, in method canStoreType(), around line 245:
  - the last case is currently: else { ArrayType aChild = (ArrayType) child;
I saw a case where the cast threw an exception. I replaced the else with else if (child instanceof ArrayType). I added a new else which just returns false.

In soot/jimple/toolkits/typing/integer/ConstraintChecker.java, in method caseAssignStmt(), around line 228:
  - the case if (!(baset instanceof NullType)) is followed by a cast of baset to ArrayType. I found a case where this cast caused a problem. I changed the condition to if (baset instanceof ArrayType).

In soot/jimple/toolkits/typing/integer/ConstraintCollector.java, in method caseAssignStmt(), around line 169, there is the same problem as above: a cast to ArrayType follows a condition different from if (baset instanceof ArrayType). Changing the condition as above solves the problem."
added a getPredsOf() to the icfg similarly to the existing getSuccsOf()
Merge pull request #38 from StevenArzt/develop

added a getPredsOf() to the icfg similarly to the existing getSuccsOf()
don't require java 7 on buildpath
factoring out computation of predecessors into distinct subclass
fixing equivTo - thanks to Michael Faes!
fix for the fix
Bugfix: getCallsFromWithin used to return only such call sites that actually have a callee; this lead to values for callee-less call sites never to be computed; the implementation is now consistent for getCallsFromWithin and for allNonCallStartNodes which should avoid this inconsistency
Fix for this problem:



Hi,

I found a performance problem and a maybe-fix for it, which speeds up my
analysis by 5x. The problem is that the active hierarchy is repeatedly
computed when calling Scene.getActiveHierarchy(). The Scene caches the
hierarchy to avoid this redundant computation, but unfortunately Body
contains the following statement (line 701):

        // FIXME: Work around for bug in soot
        Scene.v().releaseActiveHierarchy();

I.e., the cached hierarchy is deleted for each Body that is validated
(I'm using the -validate option). Is this really necessary? The
hierarchy shouldn't change while validating method bodies. As far as I
can tell from running my own analyses, removing the statement doesn't
change the behavior (except for avoiding the redundant computation).

Does anyone remember the reason for the FIXME (it's from October 2004)?
Can it be removed safely? Getting a 5x speedup with such a simple change
would be great.

Thanks,
Michael
fix: regard clinit-edges in ICFG
Do not compute string if Dexpler's debug flag is off.
update dexpler's debug print methods to avoid computing Strings if debug is disabled.
fix cast bug
bug fix: if offset == 0, must use goto/32
Merge branch 'toDexBug' into develop
Bugfix:

When -oaat and -outjar are used together, the output jar file remains empty.

That is because, even with -oaat flag, PackManager:writeOutput is called from soot.Main at line 199. I dont think there is no need for that call because with -oaat flag, the classes have already been output at that point.

The fix is to move that call to writeOutput from Soot.Main to inside the else branch in PackManager.runPacks() method.

Saswat