Method com.ibm.wala.ipa.callgraph.MethodTargetSelector.getCalleeTarget() and multiple targets

[khatchad]

The method com.ibm.wala.ipa.callgraph.MethodTargetSelector.getCalleeTarget() returns the method to be called given the caller CGNode, the CallSiteReference, and the receiver. However, what if the receiver is very general (say, Object) and thus there are potentially multiple targets given these parameters. What is supposed to be returned in this case? We can only return one IMethod, but what if there's multiple such methods?

[msridhar]

The idea behind getCalleeTarget() is to return the actual method that would be invoked if called on an object whose concrete type is the passed receiver type. So, calling getCalleeTarget() with a receiver type of Object only makes sense if the invoked method is something like toString() or hashCode() (assuming Java).

[msridhar]

In general it's hard to say and depends on the programming language. For a language with static typing that prevents such cases, I'd say it's an imprecision in the pointer analysis but not necessarily a bug. With dynamic typing it could be a real bug in the input program where the code will fail at runtime, or it could be imprecision.

[khatchad]

What I am seeing with Python is that there is a class with the same name (in fact, it's the exact same class copied) in two different files:

• https://github.com/kyzhouhzau/NLPGNN/blob/b9ecec2c6df1b3e40a54511366dcb6085cf90c34/tests/TG/EN/generation.py#L31-L41
• https://github.com/kyzhouhzau/NLPGNN/blob/b9ecec2c6df1b3e40a54511366dcb6085cf90c34/tests/TG/EN/interactive.py#L28-L38

During the execution of my overridden getCalleeTarget(), I use the PA to look up the receiver of a method in one of the (duplicate) classes that reside in different files. I get back instances of both classes, although self can never refer to an instance of the other (duplicate) class.

This situation sounds like a bug to me more so than imprecision, and I am surprised to see it because we have added the full path to the CGNode names, for example:

Add constraints from node Node: synthetic < PythonLoader, L$script tests/TG/EN/generation.py/GenGPT2/predict, trampoline3()LRoot; > Context: CallStringContext: [ script nlpgnn.sample.samples.py.sample_sequence.step.do()LRoot;@2 ]
synthetic < PythonLoader, L$script tests/TG/EN/generation.py/GenGPT2/predict, trampoline3()LRoot; >
CFG:
BB0[0..0]
    -> BB1
    -> BB5
BB1[1..1]
    -> BB2
    -> BB5
BB2[2..2]
    -> BB3
    -> BB5
BB3[3..3]
    -> BB4
    -> BB5
BB4[4..4]
    -> BB5
BB5[-1..-2]
Instructions:
BB0
0   v4 = getfield < PythonLoader, LRoot, $function, <PythonLoader,LRoot> > v1
BB1
1   v5 = checkcast <PythonLoader,Lscript tests/TG/EN/generation.py/GenGPT2/predict>v4
BB2
2   v6 = getfield < PythonLoader, LRoot, $self, <PythonLoader,LRoot> > v1
BB3
3   v7 = invokeFunction < PythonLoader, LCodeBody, do()LRoot; > v5,v6,v2,v3 @2 exception:v8
BB4
4   return v7                                
BB5

The only thing I could think about was that perhap the call stack was too long. Every call gets its own node with a call string context of seemingly length 1. But, I failed to come up with a reproducible simple test cases that exercises this behavior, even after lengthening the call stack. This case is pretty complicated with a fair amount of lexical scoping if you look at the callers of the method.

In the end, I wind up with a set of two instances for the pointer key for self, one of which represents a class in a different file.

[khatchad]

Ok. I finally reproduced this on a small example. I can confirm that it's the call length. I can only reproduce it by adding another call to the call stack. So, it does sound like imprecision.

[khatchad]

Added test case here: ponder-lab/ML#121

[khatchad]

Filed wala/ML#207.