Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interesting issue with typestate and pointer analysis combination #4

Open
khatchad opened this issue Apr 13, 2017 · 3 comments
Open

Comments

@khatchad
Copy link
Contributor

khatchad commented Apr 13, 2017

I am running into a rather interesting issue regarding the typestate analysis in combination with using pointer analysis. Assume the following simplified example:

class C {
    C m() {return new C();}  // 2.
    C n() {return this;}
    void p() {}
}

// client code:
C c = new C(); // 1.
if (...) {
    c = c.m();
    c = c.n();
} else
    c = c.n();
c.p();

Suppose I'd like to know the possible states of the objects c points to at the line c.p(). Also assume that my DFA has states, namely, "start" and "n." The "start" state is the initial state and calls to n() transitions us to state "n." The numbered comments are abstract objects created at the corresponding lines.

The points-to set of c at the call c.p() should be {1,2}. If we run the typestate analysis and use the resulting domain to give us the facts regarding these two objects at the basic block corresponding to call c.p(), we'd have that object 1 may either have the state "n" (in the case that the else branch is taken) or the state "start" (in the case that the if branch is taken). The former scenario is troubling because in the case that the if branch is taken, c would never point to object 1 because it is overwritten with object 2. As such, object 1 could only really be in the "n" state at this point.

My question is threefold:

  1. Is this an inherent limitation of typestate analysis when combined with points-to analysis? Or, am I not using the points-to analysis correctly?
  2. Is this some sort of sensitivity or precision problem that can be fixed?
  3. Or, is this a limitation of SAFE, for which it can be improved upon?
@yahave
Copy link
Contributor

yahave commented Apr 19, 2017

What typestate domain are you using? Does APMust (domain using access paths) solve your problem?

@khatchad
Copy link
Contributor Author

khatchad commented Apr 19, 2017 via email

@khatchad
Copy link
Contributor Author

khatchad commented Apr 19, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants