Open dah-fari7009 opened 2 years ago
The high memory consumption may be due to an imprecise callgraph, which in turn happens because of the imprecise PAG. Note that FlowDroid uses its own pointer analysis and does not rely on the SPARK PAG for that purpose. Still, it builds on top of the SPARK callgraph, so this issue is relevant.
Do you get a precise PAG when you disable code optimization in the InfoflowConfiguration
? If so, that would confirm your assessment of the problem. FlowDroid incrementally recomputes the callgraph (and thereby discards the old CG / PAG), so I'm not sure whether the DumbPointerAnalysis
is only an intermediate artifact. When did you notice that the DumbPointAnalysis
is used? Is that really invoked during, e.g., SetupApplication.constructCallgraph
?
Thank you for the reply!
I noticed the DumbPointerAnalysis during SetupApplication.constructCallgraph()
, after executing scene.v().addClass(exceptionClass)
in the InterProceduralConstantValuePropagator. (I am only using FD for callback extractions, not taint analysis).
It was not never reset back to PAG and remained that way:
Without dead code elimination, the analysis is precise, so the problem seems to indeed be where I identified it:
Regarding the high memory consumption, I should first clarify that my program isn't running only FlowDroid, and 128GB is the max heap memory size I allocated for the entire process. FD itself takes around ~15GB of memory to run.
Also, as I added some code to force reset the PTA after adding the exception class as a quick fix, so the analysis would remain precise, I am not sure if a high memory consumption would still be about the pointer analysis:
Thes lines are inside InterProceduralConstantValuePropagator.fixExceptions
I have added some code to restore the PAG after dead code elimination.
Same root cause for https://github.com/secure-software-engineering/FlowDroid/issues/367. Should also fix that issue, however this commit is reverted by a recent merge.
Thanks for reporting, there was indeed a problem with a merge request. I have put the fix back into the codebase.
Great, thank you!
Hi,
I am moving this issue here as it is the official repository:
I noticed that when running Flowdroid on a few applications to extract the callgraph (and the callbacks), the pointer analysis will be resolved to a DumbPointerAnalysis during the execution even though it was initially set to be PAG. After investigating, I found that this occurs in InterProceduralConstantValuePropagator when adding an exception class in case a method threw one:
When adding a new class, it seems the activePointsAnalysis is set to null, which will then default to a DumbPointerAnalysis when used:
One of the applications on which I observed this behavior is com.adobe.reader.apk which I ran with the default FlowDroid settings and 128GB of memory. Oddly enough, it doesn't seem to be regenerated for this application. The following logs only report deadcode elimination then the final number of edges of the callgraph
Thanks