Repository navigation
stdio type state analysis has a bug? #650
Description
- 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=DEBUGActual 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
Activity
MMory commentedon Aug 2, 2023
Hi @small-cat , this is indeed a bug and fixing is in progress.
MMory commentedon Aug 2, 2023
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 commentedon Sep 21, 2023
Hi @small-cat , did you find more issues with the analysis? I would like to merge the branch referenced above soon.
small-cat commentedon Sep 22, 2023
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 commentedon Oct 27, 2023
@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