Diego Garbervetsky, Mike Barnett, Manuel Fähndrich, Francesco Logozzo

Objetivos  Extender el análisis de grafos Points-to para.NET (parámetros por referencia y estructuras).  Incrementar la precisión en el análisis de efectos de métodos no analizables.

Definiciones  Método no analizable  Un método es no analizable si su código no está disponible.  Método débilmente puro  Un método es débilmente puro si no “muta” ninguna locación existente en el estado correcto anterior a la invocación del método.

El problema List Copy(IEnumerable src) { List l = new List (); IEnumerator iter = src.GetEnumerator(); while (iter.MoveNext()){ int x = iter.get_Current(); l.Add(x); } return l; }

Salcianu  Muy conservador: no puede analizar llamadas a métodos de interfaces, porque  src e iter podrían escapar a cualquier posición en memoria (tipado dinámico)  el método tiene una (potencial) escritura a cualquier posición accesible, como las variables estáticas.

Extensiones para.NET  Address nodes  Representan objetos y estructuras.  Un address node que representa un objeto tiene ejes salientes con etiqueta *.  Un address node para valores de estructuras tiene un eje saliente por campo (la etiqueta es el nombre del campo).

Ejemplo: v1 = v2 (estructura) &v0&v1 &f1&f2 &g i2 i1 * * * f1f2 g

Ejemplo: v1 = v2 (antes) &v1 &f1&f2 &g i2 i1 * * f1f2 g &v2 &f1&f2 &g i4 i3 * * f1f2 g

Ejemplo: v1 = v2 (después) &v1 &f1&f2 &g * * f1f2 g &v2 &f1&f2 &g i4 i3 * * f1f2 g

Métodos no analizables  Supongamos que tenemos un método no analizable, del que solamente sabemos que escribe sobre todo objeto alcanzable por el parámetro:  m2(p1)  p1.f1 = o;  p1.f1.f2 = o;  p1.f1.f2…fn = o;  Tenemos además otro método del que tenemos información solamente sobre a1.f1, y este método llama a m2:  m1()  …  m2(a1);

Métodos no analizables  Sería un error considerar los efectos de m2 solo sobre a1.f1.  Tenemos información insuficiente sobre el contexto de m1.  Necesitamos un mecanismo para hacer que los efectos del método llamado persistan en el contexto del método llamador, y así actualizar a1 cuando dispongamos de más información.

Extensiones para métodos no analizables (nodos)  Omega nodes (ω)  Modelan el conjunto de nodos alcanzables desde ese nodo.  Omega Confined nodes (ωC)  Subcojunto de ω. Son nodos ω que representan solo aquellos alcanzables por los campos propios del llamador.  La clase T es dueña del campo f si el objeto O de tipo T es dueño del objeto apuntado por su campo f.

Extensiones para métodos no analizables (ejes)  Ejes “?”  Representan cualquier campo existente.  Ejes “$”  Campos no propios. Permite distinguir entre referencias a objetos que pueden ser escritos por el método y los que únicamente pueden ser leídos.

Matcheo interprocedural  Matcheo con ω: calculamos el conjunto de nodos (del llamador) alcanzables desde este, y finalmente todos los load nodes se convierten en ω.  Matcheo con ωC: consideramos solo caminos que pasan por los ejes “?” y los ejes propios. Rechazamos los que contienen ejes “$”.

Ejemplo: omega nodes (método llamado) &p2 & ω2ω2ω1ω1 &p1 ** * ?

Ejemplo: omega nodes (método llamador) &f1 IN2 IN1 &a1 * * f1 &f2 L4 IN3 &a2 * * f2

Ejemplo: omega nodes (bindeando) &f1 IN2 IN1 &a1 * * f1 &f2 L4 IN3 &a2 * * f2 & & ? * * * ? *

Ejemplo: omega nodes (bindeando) &f1 IN2 IN1 &a1 * * f1 &f2 ωL4 IN3 &a2 * * f2 & & ? * * * ? *

Ejemplo: omega nodes (bindeado) &f1 IN2 IN1 &a1 * * f1 &f2 ωL4 IN3 &a2 * * f2 & & ? * * * ? *

Anotaciones

Conclusiones  Se logró extender el analisis de Salcianu para  Soportar el modelo de memoria de.NET  Tratar los métodos no analizables de manera más precisa  Mediante los nodos omega y el lenguaje de anotaciones  Verificaciones con la especificación es suficientemente simple utilizando el lenguaje de anotaciones.

Preguntas??