Skip to content

stdio type state analysis has a bug? #650

Description

@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

Activity

  1. added
    bugSomething isn't working
    on Aug 2, 2023
  2. MMory commented on Aug 2, 2023

    @MMory
    Member

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

  3. MMory commented on Aug 2, 2023

    @MMory
    Member

    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!

  4. MMory commented on Sep 21, 2023

    @MMory
    Member

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

  5. small-cat commented on Sep 22, 2023

    @small-cat
    Author

    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.

  6. fabianbs96 commented on Oct 27, 2023

    @fabianbs96
    Member

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions