Virtual Invokes only triggers getCallToReturnFlowFunction

[David Liang]

We are trying to build an IFDS Solver to trace mock objects in test suites.
We tested several types of invokes (VirtualInvoke, StaticInvoke, SpecialInvoke), and it seems like only StaticInvoke could trigger getCallFlowFunction and getReturnFlowFunction, whereas VirtualInvoke could only trigger getCallToReturnFlowFunction.
I would like to know if this is the expected behavior of heros. If so, how could I manage to trace to the method of virtualInvoke?

Our microbenchmark for testing: https://github.com/dliang2000/MockAbstraction/blob/master/Benchmarks/microbenchmark/src/test/java/ca/liang/RootDriver.java
Our developing IFDS Problem:
https://github.com/dliang2000/MockAbstraction/blob/master/src/main/java/ca/uwaterloo/liang/IFDSProblem.java

Output for objects B, C, D in testing: message.txt

Soot's Callgraph could see edges of these virtual invokes:

[Eric Bodden]

Hello. This is definitely not the intended behavior. At a virtual call, all three, the call-flow-function, the return-flow-function and the call-to-return-flow-function, should be called for each virtual call target. Maybe there’s something wrong with your callgraph? Cheers Eric On 21. Jan 2022, at 16:58, David Liang ***@***.******@***.***>> wrote: We are trying to build an IFDS Solver to trace mock objects in test suites. We tested several types of invokes (VirtualInvoke, StaticInvoke, SpecialInvoke), and it seems like only StaticInvoke could trigger getCallFlowFunction and getReturnFlowFunction, whereas VirtualInvoke could only trigger getCallToReturnFlowFunction. I would like to know if this is the expected behavior of heros. If so, how could I manage to trace to the method of virtualInvoke? Our microbenchmark for testing: https://github.com/dliang2000/MockAbstraction/blob/master/Benchmarks/microbenchmark/src/test/java/ca/liang/RootDriver.java Our developing IFDS Problem: https://github.com/dliang2000/MockAbstraction/blob/master/src/main/java/ca/uwaterloo/liang/IFDSProblem.java Output for objects B, C, D in testing: message.txt<https://github.com/Sable/heros/files/7914960/message.txt> Soot's Callgraph could see edges of these virtual invokes: [CallGraph]<https://user-images.githubusercontent.com/24902097/150558309-01a4f779-af5b-4b1d-acee-eef8580b7065.png> — Reply to this email directly, view it on GitHub<#47>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOGZPS4SW4V7JGJ5M5XCZLUXF7CTANCNFSM5MP4DC3A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Patrick Lam]

Yeah I think there's something wrong with the callgraph but I'm not sure how to figure that out. The analyzed code has an actual call to a target. I guess we can check the driver code more closely. Is there a sample driver for the example IFDS problems? pat

…

On Mon, Jan 24, 2022, 7:27 AM Eric Bodden ***@***.***> wrote: Hello. This is definitely not the intended behavior. At a virtual call, all three, the call-flow-function, the return-flow-function and the call-to-return-flow-function, should be called for each virtual call target. Maybe there’s something wrong with your callgraph? Cheers Eric On 21. Jan 2022, at 16:58, David Liang ***@***.******@***.***>> wrote: We are trying to build an IFDS Solver to trace mock objects in test suites. We tested several types of invokes (VirtualInvoke, StaticInvoke, SpecialInvoke), and it seems like only StaticInvoke could trigger getCallFlowFunction and getReturnFlowFunction, whereas VirtualInvoke could only trigger getCallToReturnFlowFunction. I would like to know if this is the expected behavior of heros. If so, how could I manage to trace to the method of virtualInvoke? Our microbenchmark for testing: https://github.com/dliang2000/MockAbstraction/blob/master/Benchmarks/microbenchmark/src/test/java/ca/liang/RootDriver.java Our developing IFDS Problem: https://github.com/dliang2000/MockAbstraction/blob/master/src/main/java/ca/uwaterloo/liang/IFDSProblem.java Output for objects B, C, D in testing: message.txt< https://github.com/Sable/heros/files/7914960/message.txt> Soot's Callgraph could see edges of these virtual invokes: [CallGraph]< https://user-images.githubusercontent.com/24902097/150558309-01a4f779-af5b-4b1d-acee-eef8580b7065.png> — Reply to this email directly, view it on GitHub< #47>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AAOGZPS4SW4V7JGJ5M5XCZLUXF7CTANCNFSM5MP4DC3A>. Triage notifications on the go with GitHub Mobile for iOS< https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android< https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOKE5UWOII255QUQ3PE5EDUXVAUVANCNFSM5MP4DC3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Eric Bodden]

Hi again. I also learned that - for whatever reason - never javac versions apparently implement (some?) virtual calls through invokedynamic! Jikes! Maybe that could be the cause of the problem? Or are you sure they really are invokevirtual instructions? Regarding the driver: I have not checked this here for a while but I think it should still work… https://github.com/Sable/heros/wiki/Example%3A-Using-Heros-with-Soot<https://github.com/Sable/heros/wiki/Example:-Using-Heros-with-Soot> Cheers Eric On 24. Jan 2022, at 14:23, Patrick Lam ***@***.******@***.***>> wrote: Yeah I think there's something wrong with the callgraph but I'm not sure how to figure that out. The analyzed code has an actual call to a target. I guess we can check the driver code more closely. Is there a sample driver for the example IFDS problems? pat

On Mon, Jan 24, 2022, 7:27 AM Eric Bodden ***@***.***> wrote: Hello. This is definitely not the intended behavior. At a virtual call, all three, the call-flow-function, the return-flow-function and the call-to-return-flow-function, should be called for each virtual call target. Maybe there’s something wrong with your callgraph? Cheers Eric On 21. Jan 2022, at 16:58, David Liang ***@***.******@***.***>> wrote: We are trying to build an IFDS Solver to trace mock objects in test suites. We tested several types of invokes (VirtualInvoke, StaticInvoke, SpecialInvoke), and it seems like only StaticInvoke could trigger getCallFlowFunction and getReturnFlowFunction, whereas VirtualInvoke could only trigger getCallToReturnFlowFunction. I would like to know if this is the expected behavior of heros. If so, how could I manage to trace to the method of virtualInvoke? Our microbenchmark for testing: https://github.com/dliang2000/MockAbstraction/blob/master/Benchmarks/microbenchmark/src/test/java/ca/liang/RootDriver.java Our developing IFDS Problem: https://github.com/dliang2000/MockAbstraction/blob/master/src/main/java/ca/uwaterloo/liang/IFDSProblem.java Output for objects B, C, D in testing: message.txt< https://github.com/Sable/heros/files/7914960/message.txt> Soot's Callgraph could see edges of these virtual invokes: [CallGraph]< https://user-images.githubusercontent.com/24902097/150558309-01a4f779-af5b-4b1d-acee-eef8580b7065.png> — Reply to this email directly, view it on GitHub< #47>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AAOGZPS4SW4V7JGJ5M5XCZLUXF7CTANCNFSM5MP4DC3A>. Triage notifications on the go with GitHub Mobile for iOS< https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android< https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOKE5UWOII255QUQ3PE5EDUXVAUVANCNFSM5MP4DC3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

— Reply to this email directly, view it on GitHub<#47 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAOGZPS6ADOP6KLS7AYLYHTUXVHEBANCNFSM5MP4DC3A>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.

[David Liang]

We originally had more options setting for cg.spark, resulted in an incomplete callgraph:

Options.v().setPhaseOption("cg.spark","enabled:true");
Options.v().setPhaseOption("cg.spark","verbose:true");
Options.v().setPhaseOption("cg.spark","on-fly-cg:true");
Options.v().setPhaseOption("cg.spark", "string-constants:true");

Now we only enable cg.spark and it triggers all flows:

Options.v().set_whole_program(true);
Options.v().setPhaseOption("cg.spark", "enabled:true");
...
PackManager.v().runPacks();

Thank you very much for the help!

Best,
David