Retrieving abstract class removes pointer analysis

[dah-fari7009]

Hi,

I noticed that both Scene.v().getSootClass("android.os.AsyncTask") and Scene.v().getSootUnsafe("android.os.AsyncTask") will turn the pointer analysis into a DumbPointerAnalysis. I assume this is what happens when attempting to retrieve an abstract class and was wondering if this is the intended behavior.

I am using the latest version on the develop branch.

Thanks

[StevenArzt]

That should not happen. If you get a DumbPointerAnalysis. this means that the old pointer analysis was released. If the pointer analysis is then requested, Soot automatically creates the dumb version as a placeholder.

If you call getSootClass, the following happens: If the class exists, the operation is read-only, and should not release the old pointer analysis. If it does not exist, a new phantom class is created. Adding new classes would normally invalidate the hierarchy. However, there is a check that does not release the hierarchy if the new class is a phantom class.

It would be great if you could debug into the issue to see why the pointer analysis still gets released.

[dah-fari7009]

Thank you for the clarifications. I will look further into it.

[dah-fari7009]

The issue seems to happen inside getSootClassUnsafe, where a new class is created, but it's not a phantom class:

"android.os.AsyncTask" does not exist as a SootClass yet, so the call to type.getSootClass() will create a new class: Inside SootResolver, makeClassRef adds a new non-phantom class using addClass which modifes the hierarchy,

This will lead to modifying the hierarchy, and thus releasing the pointer analysis:

[dah-fari7009]

What would be the desired behavior here? Is it for "android.os.AsyncTask" to be added as a phantom class instead (if it can not be found)?

In which case, possible solutions could be:

• For type.getSootClass() not to add a new class if none found (assuming it wouldn't break anything else).
• For type.getSootClass() to only be invoked if type.hasSootClass() (it could be checked within the method to make sure the issue can't occur somewhere else)

In both cases, the execution would continue in getSootUnsafe and either add a phantom class if phantomNonExist is set to true or throw an exception if set to false

If this correspond to the intended behavior, I'm happy to make a pull request :)

[dah-fari7009]

Hi, Just wanted to follow-up on this issue to see if the previous comment would be a valid solution