[Soot-list] unintended object retention/memory leak of org.objectweb.asm.tree.VarInsnNode in Soot/Dexpler

[Wei Peng]

I have figured out the root of my problem. It is cross-run memoization of
intermediate results in the batch that unintentionally retains these
objects from past runs.  - 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 Mon, Jan 5, 2015 at 11:17 PM, Wei Peng <pengw at umail.iu.edu> wrote:

> In a long running job that repeatedly processes the *same* *APK *with
> Soot/Dexpler, I observe heap exhaustion over time for both the old and
> young GC generations.
>
> Heap dump indicates that the instances of objects from the
> org.objectweb.asm.tree package (led by org.objectweb.asm.tree.VarInsnNode)
> is blamed for the heap exhaustion.
>
> In my code, the processing logic is wrapped in the clean up logic shown at
> the end, i.e.
> * do all releases in Scene.
> * nullify G's non trivial data structures:
> * reset and nullify GlobalObjectGetter.
>
> Any idea *where the leak might be*, or how can I *release the
> org.objectweb.asm.trees *after finish Soot?
>
> PS Attached are screenshots of the GC, heap usage, and heap dump (at an
> early stage---later, instances of org.objectweb.asm.tree.VarInsnNode grow
> to over 10 million) .
>
>
> (defmacro with-soot
>   "wrap body with major Soot refs *at the call time*: g, scene,
> pack-manager, options, phase-options; g can be (optionally) provided with
> g-objgetter (nil to ask fetch the G *at the call time*); (G/reset) at the
> end if \"reset?\" is true"
>   [g-objgetter reset? & body]
>   `(locking soot-mutex
>      ;; we have to use this instead of clean# due to the use in ~(when
> reset? ...)
>      (let [~'_soot-clean_ (fn []
>                             ;; null out obselete refs (Effective Java Item
> 6)
>                             (let [g# (.. ~g-objgetter getG)
>                                   s# (Scene/v)]
> *                              (doto s#*
> *                                (.releaseActiveHierarchy)*
> *                                (.releaseCallGraph)*
> *                                (.releaseFastHierarchy)*
> *                                (.releasePointsToAnalysis)*
> *                                (.releaseReachableMethods)*
> *                                (.releaseSideEffectAnalysis))*
> *                              (set! (.. g# SETBasicBlock_binding) nil)*
> *                              (set! (.. g#
> SootClassNeedsDavaSuperHandlerClass) nil)*
> *                              (set! (.. g# SootMethodsAdded) nil)*
> *                              (set! (.. g# ASTMetricsData) nil))*
> *                            (.. ~g-objgetter reset)*
> *                            (G/setGlobalObjectGetter nil)*]
>        (try
>          (System/setSecurityManager noexit-security-manager)
>          (when (instance? G$GlobalObjectGetter ~g-objgetter)
>            (G/setGlobalObjectGetter ~g-objgetter))
>          (let [~'g (G/v)
>                ~'scene (Scene/v)
>                ~'pack-manager (PackManager/v)
>                ~'options (Options/v)
>                ~'phase-options (PhaseOptions/v)]
>            ~@body
>            ~(when reset?
>               `(~'_soot-clean_)))
>          (catch Exception e#
>            ;; reset Soot state
>            (~'_soot-clean_)
>            (throw e#))
>          (finally
>            (System/setSecurityManager system-security-manager))))))
>
> 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/20150106/abd6d66a/attachment.html