[Soot-list] Multiple instances of Soot in a single host program

[Wei Peng]

Steven,

Thanks for the explanation and advice; I especially appreciate the insights
of your past experience and workarounds.

After realizing the supporting real concurrency without intrusive
modifications to Soot is not possible at this point, based on your advice,
I am serializing the critical section (Soot's analysis) with mutex. To
minimize the critical section, I take soot.Main/main(() and
soot.PackManager/runPacks() apart and just pick the parts that I need for
now ("jb"), illustrated by the following Clojure code snippet:

(def *soot-mutex*
  "Soot is unfortunately Singleton"
  (Object.))

;; inside my worker thread
(when (and apk-name (fs/readable? apk-name))
    (*locking soot-mutex*
      *(G/reset)*
      ....
         (let [scene (Scene/v)
                option (Options/v)
                pack-manager (PackManager/v)
                phase-option (PhaseOptions/v)]
            (doto option
              (.set_process_dir [apk-path])
              (.set_allow_phantom_refs true)
              (.set_src_prec (Options/src_prec_apk))
              (.set_force_android_jar android-jar-path)
              (.set_no_bodies_for_excluded true)
              (.set_whole_program true)
              (.set_output_format (Options/output_format_none)))
            (doto phase-option)
            ;; do it manually --- barebone
            (let [*reachable-classes* #(iterator-seq (.. scene
                                                       getApplicationClasses
                                                       snapshotIterator))
                  *retrieve-all-bodies* #(for [class (reachable-classes)
                                             method (iterator-seq (.. class

getMethods

iterator))
                                             :when (.. method isConcrete)]
                                         (.. method retrieveActiveBody))]
              (doto scene
                *(.loadNecessaryClasses)*)
              ;; body pack
              *(doseq [pack ["jb"]]*
*                (when-let [pack (.. pack-manager (getPack pack))]*
*                  (doseq [body (retrieve-all-bodies)]*
*                    (.. pack (apply body)))*))

Greetings,
Wei.

Wei Peng
Department of Computer and Information Science
Indiana University-Purdue University, Indianapolis (IUPUI)
pengw at iupui.edu  |  www.cs.iupui.edu/~pengw/


On Sat, Dec 27, 2014 at 11:45 AM, Steven Arzt <Steven.Arzt at cased.de> wrote:

> Hi Wei,
>
>
>
> Soot was sadly never intended to support such use cases. We have issues
> with those design decisions (that date back more than ten years) in our own
> projects as well. The best workaround we have found so far is to
> quick-switch between Soot instances. We create one copy of all singletons,
> then reset Soot, load the next instance, save it again, etc. Whenever a
> thread needs to access one of the singletons, we check which thread it is,
> get the corresponding saved generic instances, and restore them. This means
> that we cannot have real concurrency, but we can simulate the singletons
> for every thread by copying back and forth. Support for this switching has
> been added to the G class (look for “GlobalObjectGetter”).
>
>
>
> I know that this is not a real solution, but changing such low-level
> design decisions is almost impossible in a project like Soot without
> breaking almost all  current applications that use Soot.
>
>
>
> Best regards,
>
>   Steven
>
>
>
> *Von:* soot-list-bounces at CS.McGill.CA [mailto:
> soot-list-bounces at CS.McGill.CA] *Im Auftrag von *Wei Peng
> *Gesendet:* Freitag, 26. Dezember 2014 23:18
> *An:* soot-list at CS.McGill.CA
> *Betreff:* [Soot-list] Multiple instances of Soot in a single host program
>
>
>
> Hi,
>
>
>
> First, thanks for open sourcing Soot and keeping on making it better after
> so many years.
>
>
>
> I have searched but not found any answer to my following question.
>
>
>
> It appears to me that Soot is designed to be Singleton, evidenced by the
> ubiquitous .v() calls for retrieving the root objects (Scene, Main, etc).
> However, if I want to do *separate* analyses on *totally different set of
> classes* in a *single host* program, the global states shared by
> Singleton would interfere with each other.
>
>
>
> My questions are:
>
> * How can I host multiple instances of Soot in a single program?
>
> * If it is not possible without making intrusive changes to Soot, can I
> somehow reset the global state?
>
>
>
> What I have found that maybe relevant:
>
> * G.v().reset()
>
>
>
> *Use case *I have a host program that uses Soot to construct
> SootMethod/SootClass, on which the host program will extract info. The host
> program takes a bunch of Android APK names from STDIN, and farms out
> *isolated* analyses of the APKs to a pool of worker threads. One step in
> these worker threads is to use Soot to construct SootMethod of the APK
> (using the "jb" pack). However, the Singleton architecture of Soot would
> prevent me from doing this.
>
>
>
> *Motivation* All the benefits of using a single JVM to do multiple tasks:
> Saving JVM start time, using lightweight theads instead of OS processes,
> cache warming, control parallelism through FixedThreadPool instead of using
> GNU Make "-j" trick, etc.
>
>
>
> Wei.
>
>
>
> Wei Peng
> Department of Computer and Information Science
> Indiana University-Purdue University, Indianapolis (IUPUI)
> pengw at iupui.edu  |  www.cs.iupui.edu/~pengw/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20141227/4a8eb352/attachment.html