stdio type state analysis has a bug?

[small-cat]

• I have searched open and closed issues for duplicates
• I made sure that I am not using an old project version (DO: pull Phasar, update git submodules, rebuild the project and check if the bug is still there)

---

Bug description

the result is not correct when I use phasar-cli to check the following example. (See the files below)

Steps to reproduce

./phasar-cli -m fopen-test-5.bc -C dta -D ide-stdio-ts --log --log-level=DEBUG

Actual result: The result is correct when analyze the procedure myfunc3, the status is ERROR at the exit statement.
But I have two doubts,

• first, before go into the procedure myfunc3, the getCallFlowFunction can not deliver the data factor (fopen) to the start point of the procedure myfunc3, and result in that phasar could not know the status is OPEN before.
• second, and the incorrect one, after analyzing the procedure myfun3, and back to procedure failed_test3, the ERROR status could not deliver to procedure myfunc3, and result in the status is not correct when fwrite called after myfunc3. But here, if I deliver the ERROR status to failed_test3 by getRetCallFlowFunction(exit to return site), the edge function TSConstant(ERROR) join with the CallToRetEdgeFunction will get the AllBottom.

It is a bug, or my misunderstand?

Context (Environment)

I pull the latest version from development branch.

Operating System:

• Linux
• Windows
• macOS

Build Type:

• cmake
• custom build

Files:
test.tar.gz

[MMory]

Hi @small-cat , this is indeed a bug and fixing is in progress.

[MMory]

Hi @small-cat , could you please try https://github.com/secure-software-engineering/phasar/tree/f-FixTSAGlobalHandling? I assume you might find more issues, so I am not merging that branch to development yet. Thank you for your tests!

[MMory]

Hi @small-cat , did you find more issues with the analysis? I would like to merge the branch referenced above soon.

[small-cat]

Yes, I found another problem. When I use phasar to analyze kernel, the one is that phasar use llvm::CFLAnderson algorithm to analyze kernel code which cause an OOM error, the algorithm seems can not stop, and I should to change to use CFLSteens algorithm, and I made a issue before about this problem. Another one is that at the buildLLVMTypeHierarchy function when analyze kernel code, use the boost::transitive_closure interface cost too much memory and may lead to an OOM error, I change to use the boost::breadth_first_search to iterate the TypeGraph and solve the problem.

[fabianbs96]

@small-cat, you are right. We are aware of the alias analysis problem (see #329, #610). We are also working on a different type-hierarchy solution #623; however, it will still take some time to complete