cargaji/tfm-report
cargaji/tfm-report
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

solution for try-catch problem and graphs

Browse source
This commit is contained in:
Carlos Galindo 2019-12-08 14:49:52 +00:00
parent 743093c3d5
commit 904b44e229
9 changed files with 341 additions and 95 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Makefile
View file

@ -14,4 +14,4 @@ paper.pdf: paper.tex images
clean:
rm -f Secciones/*.aux
rm -f *.toc *.aux *.bbl *.blg *.fls *.out *.log *.synctex.gz
$(MAKE) -C img clean
# $(MAKE) -C img clean

326
Secciones/problem_solution.tex
View file

@ -191,116 +191,254 @@ This problem cannot be easily solved, as it is a ``dynamic'' one, requiring info
\section{The \texttt{try-catch} statement}
\subsection{The problem with the control dependency's definition}
In this section we present an example where the current approximation for the \texttt{try-catch} statement fails to capture all the correct dependencies and excludes from the slice some statements which are necessary for a complete slice (both weak and strong). After that, we generalize the set of cases where that is a problem and its possible appearances in real-life development. Finally, we propose a solution which properly represent all the dependencies introduced by the \texttt{try-catch}, focusing on producing complete strong slices.
\section{Previous text}
\carlos{Here begins the old text.}
\hrulefill
\subsubsection*{The types of control dependence}
This solution is an extension of Allen's \cite{AllH03}, with some modifications to solve the problem found \josep{el problem found no ha quedado claro. Se ha diluido entre la maraña abrumadora de casos. debes formular y dejar nitido cristalino cual es el problema y por qué no lo solucinan las dsemás aproximaciones, y poner un ejempllo concreto.}. Before starting, we need to split all instructions in three categories:
\carlos{this subsection snippet could go in another place}
\begin{description}
\item[statement] non-branching instruction, e.g. an assignment or method call.
\item[predicate] conditional branch, e.g. if statements and loops.
\item[pseudo-predicate] unconditional jump, e.g. break, continue, return, goto and throw instructions.
\end{description}
Even though it continues to be used for control dependence, definition~\ref{def:ctrl-dep} does not have the same meaning when applied to conditional instructions and loops as it has when applied to unconditional jumps and other complex structures, such as the \texttt{switch} and \texttt{try-catch} statements.
Pseudo-predicates have been previously use to model unconditional jumps with a counter-intuitive reasoning: the next statement that would be executed were the pseudo-predicate not there would be executed, therefore it is control dependent on it. Going back to the definition of control dependency, one could argue that the real control dependency is on the conditional branch that lead to the \josep{???}
Originally, the definition of control dependence signified that the execution of a statement affected whether or not another one executed (or kept executing). In contrast, unconditional jumps, and \texttt{try-catch} statements' execution do not affect the following instructions; its presence or absence is what generates the control dependency. For those instructions, control dependencies are still generated with the same edges, but require the addition of extra edges to the CFG \cite{BalH93,AllH03}.
\begin{figure}
\centering
\begin{lstlisting}
if (a) {
return a;
\subsection{The control dependencies of a \texttt{catch} block}
In the current approximation for exception handling \cite{AllH03}, \texttt{catch} blocks do not have any outgoing dependence leading anywhere except the instructions it contains. This means that, as showcased in chapter~\ref{cha:introduction}, the only way a \texttt{catch} statement may appear in a slice is if there is a data dependency or one of the statements inside it is needed.
The only occasion in which \texttt{catch} blocks generate any kind of control dependency is when there is an exception thrown that is not covered by any of the \texttt{catch} blocks, and the function may exit with an exception. In that case, the instructions after the \texttt{try-catch} block are dependent on an uncaught exception not being thrown.
But, compared to the treatment of unconditional exceptions does not match the treatment of \texttt{try-catch} statement: unconditional jumps have a non-executable edge to the instruction that would be executed in their absence; \texttt{catch} statements do not.
\begin{example}[\texttt{catch} statements' outgoing dependencies]
Consider the code shown in figure~\ref{fig:catch-no-dep-code}, which depicts a \texttt{try-catch} where method \texttt{f}, which may throw an exception, is called. The function may throw either a \texttt{ExceptionA}, \texttt{ExceptionB} or \texttt{Exception}-typed exception; and the \texttt{try-catch} considers all three cases, logging the type of exception caught. Additionally, \texttt{f} accesses and modifies a global variable \texttt{x}.
\begin{figure}[h]
\begin{lstlisting}
try {
f();
} catch (ExceptionA e) {
log("Type A");
} catch (ExceptionB e) {
log("Type B");
} catch (Exception e) {
log("Exception");
}
print(a);
\end{lstlisting}
\begin{lstlisting}
if (a) {
next;
\end{lstlisting}
\caption{A snippet of code of a call to a method that throws exceptions and \texttt{catch} statements to capture and log them.}
\label{fig:catch-no-dep-code}
\end{figure}
The CFG and PDG associated to that code is depicted in figure~\ref{fig:catch-no-dep-graphs}. As can be seen, the only two elements that are dependent on any \texttt{catch} are the log statement and the unpacking of \texttt{x}. If the following statement used \texttt{x} in any way, all \texttt{catch} statements would be selected, otherwise they are ignored, and not deemed necessary. It is true that they are normally not necessary; i.e., if the slicing criterion was placed on \texttt{next} (line 10), the whole \texttt{try-catch} would be rightfully ignored; but there exist cases where \texttt{f()} (line 2) would be part of the slice, and the absence of \texttt{catch} statements would result in an incomplete slice.
\begin{figure}[h]
\includegraphics[width=\linewidth]{img/catch-no-dep}
\caption{CFG (left) and PDG (right) of the code shown in figure~\ref{fig:catch-no-dep-code}.}
\label{fig:catch-no-dep-graphs}
\end{figure}
\end{example}
\begin{example}[Incorrectly ignored \texttt{catch} statements]
Consider the code in figure~\ref{fig:incorrect-try-catch-code}, in which a method is called twice: once inside a \texttt{try-catch} statement, and a second time, outside. \texttt{f} also accesses and modifies variable \texttt{x}, which is redefined before the second call to \texttt{f}. Exploring this example, we demonstrate how line 3 will be necessary but not included in the slice.
\begin{figure}[h]
\begin{minipage}{0.5\linewidth}
\begin{lstlisting}
try {
f();
} catch (Exception e) {
log("error");
}
print(a);
\end{lstlisting}
\caption{Example of pseudo-predicates control dependencies \josep{no se referencia a esta figura desde ningún sitio}}
\end{figure}
x = 0;
f();
\end{lstlisting}
\end{minipage}
\begin{minipage}{0.49\linewidth}
\begin{lstlisting}
void f() throws Exception {
if (x % 2 != 0)
throw new Exception();
x++;
}
\end{lstlisting}
\end{minipage}
\caption{A method that may throw exceptions (\texttt{f}), called twice, once surrounded by a \texttt{try-catch} statement, and another time after it. On the right, the definition of \texttt{f}.}
\label{fig:incorrect-try-catch-code}
\end{figure}
This is the process used to build the Program Dependence Graph. \josep{Todo lo que sigue es demasiado verbose. No hay definiciones concretas. Es todo muy informal, y no hay un ongoing example que permita ver como las fases van evolucionando paso a paso. Nos reunimos para hablar de esta sección antes de reescribirla...}
Figure~\ref{fig:incorrect-try-catch-graph} displays the program dependence graph for the snippet of code on the left side of figure~\ref{fig:incorrect-try-catch-code}. Data dependencies are shown in red, and summary edges in blue. The set of nodes filled in grey represent the slice with respect to a slicing criterion in method \texttt{f} (line 4, \texttt{x}). In the slice, both calls to \texttt{f} and its input (\texttt{x\_in = x}) are included, but the \texttt{catch} block is not present. The execution of the slice may not be the same: if no exception is thrown, there is no change; but if \texttt{x} was odd before entering the snippet, an exception will be thrown and not caught, exiting the program prematurely.
\begin{description}
\item[Step 1 (static analysis):] Identify for each instruction the variables read and defined. Each method is annotated with the global variables that they access or modify.
\item[Step 2 (build CFGs):] Build a CFG for each method of the program. The start of all methods is a vertex labeled \textsl{enter}, which also contains the assignments for parameters and global variables used (\texttt{var = var\_in}). The \textsl{enter} node is connected to the first instruction of the method. In a similar fashion, all methods end in an \textsl{exit} vertex with the corresponding output variables. There exists one \textsl{normal exit} to which the last instruction and all return instructions are connected. If the method can throw any exceptions, there exists one \textsl{error exit} for each type of exception that may be thrown. The normal and erroneous exits are connected to the \textsl{exit} node.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\linewidth]{img/incorrect-try-catch}
\caption{The system dependence graph of the left snippet of figure~\ref{fig:incorrect-try-catch-code}. \texttt{f} and the edges that connect to it are not shown for simplicity.}
\label{fig:incorrect-try-catch-graph}
\end{figure}
\end{example}
Every normal statement is connected to the subsequent one by an unlabeled edge. Predicates have two outgoing edges, labeled \textsl{true} and \textsl{false}. Pseudo-predicates also have two outgoing edges. The \textsl{true} edge is connected to the destination of the jump (\textsl{normal exit} in the case of return, the begin or end of the loop in the case of continue and break, etc.). The \textsl{false} edge is a non-executable edge, marked with a dashed line, and it is connected to the next instruction that would be executed if the pseudo-predicate was a \textsl{nop}.
Nodes that represent a call to a method $M$ include the transfer of parameters and variables that may be read or written to, then execute the call, and finally the extraction of modified variables. Call nodes are an exception to the previous paragraph, as they can have an unlimited amount of outgoing edges. Each outgoing edge lands on a pseudo-predicate which indicates if the execution was correct or an exception was raised. The executable edge of each pseudo-predicate will lead to the next instruction to be executed, whereas the non-executable one will lead to the end of the try-catch block. All call nodes can lead to a \textsl{normal return} node, which is linked to the next instruction, and one error node for each type of exception that may be thrown. The erroneous returns are labeled \textsl{catch ExType}, and lead to the first instruction in the corresponding catch block\footnotemark. Any exception that may not be caught will lead to the erroneous exit node of the method it's in. See the example for more details.
\subsubsection*{A solution for the \texttt{catch}'s lack of control dependencies}
\footnotetext{A problem presents itself here, as some exceptions may be able to trigger different catch blocks, due to the secuential nature of catches and polymorphism in Java. A way to fix this is to make catch blocks behave as a switch.}. %TODO
\texttt{catch} statements should be handled like unconditional jumps: a non-executable edge should connect them to the instruction that would run if they were absent. For \texttt{catch} statements, the non-executable edge would connect them to the \texttt{catch} that contains the most immediate super-type (or multiple); or to the error exit, if no other \texttt{catch} could catch the same exception. This would create a tree-like structure among \texttt{catch} statements, with the root of each tree connected to the ``error exit'' of the method. This would generate dependencies between \texttt{catch} statements, and more importantly, dependencies from the \texttt{catch} statements to the instructions that follow the \texttt{try-catch} statement.
\item[Step 3 (compute dependences):] For each node in the CFG, compute the control and data dependencies. Non-executable edges are only included when computing control dependencies.\\
\carlos{put inside definition}
A node $a$ is \textsl{control dependent} on node $b$ iff $a$ post-dominates one but not all of $b$'s successors.\\
A node $a$ is \textsl{data dependent} on node $b$ iff $b$ defines or may define a variable $x$, $a$ uses or may use $x$, and there is an $x$-definition-free path in the CFG from $b$ to $a$.\\
\item[Step 4 (convert each CFG into a PDG):] each node of the CFG is one node of the PDG, with two exceptions. The first are the \textsl{enter}, \textsl{exit} and method call nodes, where the variable input and output assignments are split and placed as control-dependent on their original node. The second is the \textsl{exit} node, which is to be removed (the control-dependencies from \textsl{exit} to the variable outputs is transferred to the \textsl{enter} node). Then all the dependencies computed in the previous step are drawn.
\item[Step 5 (connect PDGs to form a SDG):] each method call to $M$ must be connected to the \textsl{enter} node in $M$'s PDG, as a control dependence. Each variable input from the method call is connected to a variable input of the method definition via a data dependence. Each variable output from the method definition is connected to the variable output of the method call via a data dependence. Each method exit is connected \carlos{complete}.
\end{description}
Unfortunately, this creates the same behaviour as with unconditional jumps: all the instructions that follow a \texttt{try-catch} structure is dependent on the presence of the \texttt{catch} statements, which in turn are dependent on all the statements that may throw exceptions. In practice, the inclusion of any statement after a \texttt{try-catch} statement would require the slice to include all \texttt{catch} statements, the statements that may throw exceptions, and all the statements required by control or data dependencies. This is a huge number of instructions just for including the \texttt{catch} statements.
\begin{itemize}
\item An extra type of control dependency represented by an ``exception edge''. It will represent the need to include a \textsl{catch} clause when an exception can be thrown. It is represented with a dotted line (dashed line is for data dependency). These edges have a special characteristic: when one is traversed, only ``exception edges'' may be traversed from the new nodes included in the slice. If the same node is reached by another kind of edge, the restriction is lifted. The behavior is documented in algorithm \ref{alg:2pass}, with changes from the original algorithm are \underline{underlined}.
\item Add an extra ``exception edge'' from each ``exit with exception of type T'' node, where the type of the exception is \texttt{t} to all the corresponding ``\texttt{throw e}'', such that \texttt{e} is or inherits from \texttt{T}.
\item Add an extra ``exception edge'' from each catch statement to every statement that can throw that error.
\item The exception edges will only be placed when the method or the try-catch statement are loop-carrier\footnote{Loop-carrier, when referring to a statement, is the property that in a CFG for the complete program, the node representing the statement is part of a loop, meaning that it could be executed again once it is executed.}.
\end{itemize}
Our solution makes slices complete again, but makes them much less correct. As a solution for the incorrectness, we could insert an additional requirement when including \texttt{catch} blocks: if they are included because of their control dependencies on instructions outside the \texttt{try-catch}, they need to satisfy an additional condition before being in the slice: have a node in the slice which may throw a compatible exception. In order to achieve this, control dependencies whose source is a \texttt{catch} node and its destination is outside that same \texttt{catch} are coloured green and labelled (2). Additional edges are added between every \texttt{catch} and any statement that may throw a compatible exception; are also coloured green, and labelled (1). When traversing the graph, only include \texttt{catch} statements if they are reached through an unlabelled edge or if they are reached by at least one edge with each label (1 and 2). \carlos{Add que solo se pueda atravesar uno de los arcos verdes (una vez llegas a un nodo a traves de un arco verde, no continuas recorriendo arcos verdes)} \carlos{optimizacion 2, que los nodos catch se repitan para cada funcion tenga los suyos propios. El contenido del catch es comun a todos, pero las cabeceras y el despempaquetamiento de variables es individual para cada funcion. De este modo no se coge a todas las funciones. Tambien se podria emplear como alternativa a los arcos etiquetados, creando un set de nodos que no tienen padre, y sirven exclusivamente para que las instrucciones futuras dependan de ellas.}
\begin{algorithm} % generate slice
\caption{Two-pass algorithm to obtain a backward static slice with exceptions}
\label{alg:2pass}
\begin{algorithmic}[1]
\REQUIRE SDG $\mathcal{G}$ representing program P. $\mathcal{G} = \{\mathcal{S}, \mathcal{E}\}$, where $\mathcal{S}$ is a set of states (some are statements) connected by a set of edges $\mathcal{E}$. Each edge, is a triplet composed of the type of edge (control, data or \underline{exception} dependency, summary, param-in, param-out), the source and destination of the edge.
\REQUIRE A slicing criterion, composed of a statement $s \in \mathcal{S}$ and a variable $v$.
\ENSURE $\mathcal{S}' \subseteq \mathcal{S}$, representing the slice of P according to the criterion provided.
\medskip
\COMMENT{First pass (do not traverse output parameter edges).}
\STATE{$\mathcal{S}' \Leftarrow \emptyset$ (slice), $\mathcal{Q}\Leftarrow\{s\}$ (queue), $\mathcal{S}\Leftarrow \mathcal{S} - \{s\}$ (not visited), $\mathcal{R}\Leftarrow \emptyset$ (only visited via exception edge)}
\WHILE{$\mathcal{Q} \neq \emptyset$}
\STATE{$a \in \mathcal{Q}$} \COMMENT{Select an element from $\mathcal{Q}$}
\STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} - \{a\}$}
\STATE{$\mathcal{S}' \Leftarrow \mathcal{S}' + \{a\}$}
\FORALL{$\mathcal{A}$ in $\{\{type, origin, a\} \in \mathcal{E}\}$}
\IF{$type \neq$ param-out \AND ($origin \notin \mathcal{S}'$ \OR ($origin \in \mathcal{R}$ \AND $a \notin \mathcal{R}$))} \label{line:param-out}
\IF{\underline{$a \in \mathcal{R}$}}
\IF{\underline{$type =$ exception}}
\STATE{\underline{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}}
\STATE{\underline{$\mathcal{R} \Leftarrow \mathcal{R} + \{origin\}$}}
\ENDIF
\ELSE
\STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}
\ENDIF
\ENDIF
\ENDFOR
\ENDWHILE
\\
\medskip
\COMMENT{Second pass (very similar, do not traverse input parameter edges).}
\STATE $\mathcal{Q} \Leftarrow \mathcal{S}'$
\WHILE{$\mathcal{Q} \neq \emptyset$}
\STATE{$a \in \mathcal{Q}$} \COMMENT{Select an element from $\mathcal{Q}$}
\STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} - \{a\}$}
\STATE{$\mathcal{S}' \Leftarrow \mathcal{S}' + \{a\}$}
\FORALL{$\mathcal{A}$ in $\{\{type, origin, a\} \in \mathcal{E}\}$}
\IF{$type \neq$ param-in \AND ($origin \notin \mathcal{S}'$ \OR ($origin \in \mathcal{R}$ \AND $a \notin \mathcal{R}$))}
\IF{\underline{$a \in \mathcal{R}$}}
\IF{\underline{$type =$ exception}}
\STATE{\underline{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}}
\STATE{\underline{$\mathcal{R} \Leftarrow \mathcal{R} + \{origin\}$}}
\ENDIF
\ELSE
\STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}
\ENDIF
\ENDIF
\ENDFOR
\ENDWHILE
\end{algorithmic}
\end{algorithm}
% \begin{example}[Order of \texttt{catch} statements]
% Consider the following exception types declared in figure~\ref{fig:catch-order-code}, and their ordering in a simple \texttt{try-catch} statement. The \texttt{catch} blocks may be reorganized in any order if the type
% \begin{figure}[h]
% \begin{minipage}{0.60\linewidth}
% \begin{lstlisting}
% class ExceptionA extends Exception {...};
% class ExceptionB extends Exception {...};
% class ExceptionB1 extends ExceptionB {...};
% class ExceptionB2 extends ExceptionB {...};
% \end{lstlisting}
% \end{minipage}
% \begin{minipage}{0.39\linewidth}
% \begin{lstlisting}
% try {
% [...]
% } catch (ExceptionB2 e) {
% [...]
% } catch (ExceptionA e) {
% [...]
% } catch (ExceptionB1 e) {
% [...]
% } catch (ExceptionB e) {
% [...]
% } catch (Exception e) {
% [...]
% }
% \end{lstlisting}
% \end{minipage}
% \caption{A set of type declarations that extend the class \texttt{Exception} (left) and a small \texttt{try-catch} with the exceptions sorted in one of the valid orders (right).}
% \label{fig:catch-order-code}
% \end{figure}
% \end{example}
% \texttt{catch} blocks can be organized in two different orders: the physical order in which they are placed by the developer, which is the order in which they will be evaluated to check for type compatibility (in Java specifically); or a tree-like structure according to their types. Figure~\ref{fig:catch-order} showcases a couple of examples of each order. In Java's case, the tree structure is more correct; because though the order ``seems'' to matter, there is only one possible execution order.
% \begin{figure}
% \centering
% \includegraphics[width=0.5\linewidth]{img/catch-order}
% \caption{Two ways of looking at \texttt{catch} block orders: user-specified (left) and type-based tree (right).}
% \label{fig:catch-order}
% \end{figure}
% \newpage
% \section{Previous text}
% \carlos{Here begins the old text.}
% \hrulefill
% This solution is an extension of Allen's \cite{AllH03}, with some modifications to solve the problem found \josep{el problem found no ha quedado claro. Se ha diluido entre la maraña abrumadora de casos. debes formular y dejar nitido cristalino cual es el problema y por qué no lo solucinan las dsemás aproximaciones, y poner un ejempllo concreto.}. Before starting, we need to split all instructions in three categories:
% \begin{description}
% \item[statement] non-branching instruction, e.g. an assignment or method call.
% \item[predicate] conditional branch, e.g. if statements and loops.
% \item[pseudo-predicate] unconditional jump, e.g. break, continue, return, goto and throw instructions.
% \end{description}
% Pseudo-predicates have been previously use to model unconditional jumps with a counter-intuitive reasoning: the next statement that would be executed were the pseudo-predicate not there would be executed, therefore it is control dependent on it. Going back to the definition of control dependency, one could argue that the real control dependency is on the conditional branch that lead to the \josep{???}
% \begin{figure}
% \centering
% \begin{lstlisting}
% if (a) {
% return a;
% }
% print(a);
% \end{lstlisting}
% \begin{lstlisting}
% if (a) {
% }
% print(a);
% \end{lstlisting}
% \caption{Example of pseudo-predicates control dependencies \josep{no se referencia a esta figura desde ningún sitio}}
% \end{figure}
% This is the process used to build the Program Dependence Graph. \josep{Todo lo que sigue es demasiado verbose. No hay definiciones concretas. Es todo muy informal, y no hay un ongoing example que permita ver como las fases van evolucionando paso a paso. Nos reunimos para hablar de esta sección antes de reescribirla...}
% \begin{description}
% \item[Step 1 (static analysis):] Identify for each instruction the variables read and defined. Each method is annotated with the global variables that they access or modify.
% \item[Step 2 (build CFGs):] Build a CFG for each method of the program. The start of all methods is a vertex labeled \textsl{enter}, which also contains the assignments for parameters and global variables used (\texttt{var = var\_in}). The \textsl{enter} node is connected to the first instruction of the method. In a similar fashion, all methods end in an \textsl{exit} vertex with the corresponding output variables. There exists one \textsl{normal exit} to which the last instruction and all return instructions are connected. If the method can throw any exceptions, there exists one \textsl{error exit} for each type of exception that may be thrown. The normal and erroneous exits are connected to the \textsl{exit} node.
% Every normal statement is connected to the subsequent one by an unlabeled edge. Predicates have two outgoing edges, labeled \textsl{true} and \textsl{false}. Pseudo-predicates also have two outgoing edges. The \textsl{true} edge is connected to the destination of the jump (\textsl{normal exit} in the case of return, the begin or end of the loop in the case of continue and break, etc.). The \textsl{false} edge is a non-executable edge, marked with a dashed line, and it is connected to the next instruction that would be executed if the pseudo-predicate was a \textsl{nop}.
% Nodes that represent a call to a method $M$ include the transfer of parameters and variables that may be read or written to, then execute the call, and finally the extraction of modified variables. Call nodes are an exception to the previous paragraph, as they can have an unlimited amount of outgoing edges. Each outgoing edge lands on a pseudo-predicate which indicates if the execution was correct or an exception was raised. The executable edge of each pseudo-predicate will lead to the next instruction to be executed, whereas the non-executable one will lead to the end of the try-catch block. All call nodes can lead to a \textsl{normal return} node, which is linked to the next instruction, and one error node for each type of exception that may be thrown. The erroneous returns are labeled \textsl{catch ExType}, and lead to the first instruction in the corresponding catch block\footnotemark. Any exception that may not be caught will lead to the erroneous exit node of the method it's in. See the example for more details.
% \footnotetext{A problem presents itself here, as some exceptions may be able to trigger different catch blocks, due to the secuential nature of catches and polymorphism in Java. A way to fix this is to make catch blocks behave as a switch.}. %TODO
% \item[Step 3 (compute dependences):] For each node in the CFG, compute the control and data dependencies. Non-executable edges are only included when computing control dependencies.\\
% \carlos{put inside definition}
% A node $a$ is \textsl{control dependent} on node $b$ iff $a$ post-dominates one but not all of $b$'s successors.\\
% A node $a$ is \textsl{data dependent} on node $b$ iff $b$ defines or may define a variable $x$, $a$ uses or may use $x$, and there is an $x$-definition-free path in the CFG from $b$ to $a$.\\
% \item[Step 4 (convert each CFG into a PDG):] each node of the CFG is one node of the PDG, with two exceptions. The first are the \textsl{enter}, \textsl{exit} and method call nodes, where the variable input and output assignments are split and placed as control-dependent on their original node. The second is the \textsl{exit} node, which is to be removed (the control-dependencies from \textsl{exit} to the variable outputs is transferred to the \textsl{enter} node). Then all the dependencies computed in the previous step are drawn.
% \item[Step 5 (connect PDGs to form a SDG):] each method call to $M$ must be connected to the \textsl{enter} node in $M$'s PDG, as a control dependence. Each variable input from the method call is connected to a variable input of the method definition via a data dependence. Each variable output from the method definition is connected to the variable output of the method call via a data dependence. Each method exit is connected \carlos{complete}.
% \end{description}
% \begin{itemize}
% \item An extra type of control dependency represented by an ``exception edge''. It will represent the need to include a \textsl{catch} clause when an exception can be thrown. It is represented with a dotted line (dashed line is for data dependency). These edges have a special characteristic: when one is traversed, only ``exception edges'' may be traversed from the new nodes included in the slice. If the same node is reached by another kind of edge, the restriction is lifted. The behavior is documented in algorithm \ref{alg:2pass}, with changes from the original algorithm are \underline{underlined}.
% \item Add an extra ``exception edge'' from each ``exit with exception of type T'' node, where the type of the exception is \texttt{t} to all the corresponding ``\texttt{throw e}'', such that \texttt{e} is or inherits from \texttt{T}.
% \item Add an extra ``exception edge'' from each catch statement to every statement that can throw that error.
% \item The exception edges will only be placed when the method or the try-catch statement are loop-carrier\footnote{Loop-carrier, when referring to a statement, is the property that in a CFG for the complete program, the node representing the statement is part of a loop, meaning that it could be executed again once it is executed.}.
% \end{itemize}
% \begin{algorithm} % generate slice
% \caption{Two-pass algorithm to obtain a backward static slice with exceptions}
% \label{alg:2pass}
% \begin{algorithmic}[1]
% \REQUIRE SDG $\mathcal{G}$ representing program P. $\mathcal{G} = \{\mathcal{S}, \mathcal{E}\}$, where $\mathcal{S}$ is a set of states (some are statements) connected by a set of edges $\mathcal{E}$. Each edge, is a triplet composed of the type of edge (control, data or \underline{exception} dependency, summary, param-in, param-out), the source and destination of the edge.
% \REQUIRE A slicing criterion, composed of a statement $s \in \mathcal{S}$ and a variable $v$.
% \ENSURE $\mathcal{S}' \subseteq \mathcal{S}$, representing the slice of P according to the criterion provided.
% \medskip
% \COMMENT{First pass (do not traverse output parameter edges).}
% \STATE{$\mathcal{S}' \Leftarrow \emptyset$ (slice), $\mathcal{Q}\Leftarrow\{s\}$ (queue), $\mathcal{S}\Leftarrow \mathcal{S} - \{s\}$ (not visited), $\mathcal{R}\Leftarrow \emptyset$ (only visited via exception edge)}
% \WHILE{$\mathcal{Q} \neq \emptyset$}
% \STATE{$a \in \mathcal{Q}$} \COMMENT{Select an element from $\mathcal{Q}$}
% \STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} - \{a\}$}
% \STATE{$\mathcal{S}' \Leftarrow \mathcal{S}' + \{a\}$}
% \FORALL{$\mathcal{A}$ in $\{\{type, origin, a\} \in \mathcal{E}\}$}
% \IF{$type \neq$ param-out \AND ($origin \notin \mathcal{S}'$ \OR ($origin \in \mathcal{R}$ \AND $a \notin \mathcal{R}$))} \label{line:param-out}
% \IF{\underline{$a \in \mathcal{R}$}}
% \IF{\underline{$type =$ exception}}
% \STATE{\underline{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}}
% \STATE{\underline{$\mathcal{R} \Leftarrow \mathcal{R} + \{origin\}$}}
% \ENDIF
% \ELSE
% \STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}
% \ENDIF
% \ENDIF
% \ENDFOR
% \ENDWHILE
% \\
% \medskip
% \COMMENT{Second pass (very similar, do not traverse input parameter edges).}
% \STATE $\mathcal{Q} \Leftarrow \mathcal{S}'$
% \WHILE{$\mathcal{Q} \neq \emptyset$}
% \STATE{$a \in \mathcal{Q}$} \COMMENT{Select an element from $\mathcal{Q}$}
% \STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} - \{a\}$}
% \STATE{$\mathcal{S}' \Leftarrow \mathcal{S}' + \{a\}$}
% \FORALL{$\mathcal{A}$ in $\{\{type, origin, a\} \in \mathcal{E}\}$}
% \IF{$type \neq$ param-in \AND ($origin \notin \mathcal{S}'$ \OR ($origin \in \mathcal{R}$ \AND $a \notin \mathcal{R}$))}
% \IF{\underline{$a \in \mathcal{R}$}}
% \IF{\underline{$type =$ exception}}
% \STATE{\underline{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}}
% \STATE{\underline{$\mathcal{R} \Leftarrow \mathcal{R} + \{origin\}$}}
% \ENDIF
% \ELSE
% \STATE{$\mathcal{Q} \Leftarrow \mathcal{Q} + \{origin\}$}
% \ENDIF
% \ENDIF
% \ENDFOR
% \ENDWHILE
% \end{algorithmic}
% \end{algorithm}
% vim: set noexpandtab:ts=2:sw=2:wrap

51
img/catch-no-dep.dot Normal file
View file

@ -0,0 +1,51 @@
digraph g {
before [label = "", style=invis, width =0.001, height = 0.001];
t [label = "try"];
f [label = <x_in = x<br/>f()>];
er [label = "error return"];
nr [label = "normal return"];
o [label = "x = x_out"];
o1 [label = "x = x_out"];
o2 [label = "x = x_out"];
o3 [label = "x = x_out"];
c1 [label = "catch (ExceptionA e)"]
c2 [label = "catch (ExceptionB e)"]
c3 [label = "catch (Exception e)"]
l1 [label = "log(\"Type A\")"];
l2 [label = "log(\"Type B\")"];
l3 [label = "log(\"Exception\")"];
after [label = "next"];
after2 [label = "", style= invis, height = 0.0001, width = 0.0001]
before -> t -> f -> er -> {c1, c2, c3};
f -> nr -> o -> after;
c1 -> o1 -> l1;
c2 -> o2 -> l2;
c3 -> o3 -> l3;
{t nr c1 c2 c3} -> after [style = dashed, constraint = false];
{l1 l2 l3} -> after -> after2;
BEFORE [label = "", style = invis, width = 0.001, height = 0.001];
T [label = "try"];
F [label = "f()"];
X_IN [label = "x_in = x"];
X_OUT_NORMAL [label = "x = x_out"];
X_OUT_1 [label = "x = x_out"];
X_OUT_2 [label = "x = x_out"];
X_OUT_3 [label = "x = x_out"];
NORMAL_RET [label = "normal return"];
ERROR_RET [label = "error return"];
C1 [label = "catch (ExceptionA e)"]
C2 [label = "catch (ExceptionB e)"]
C3 [label = "catch (Exception e)"]
L1 [label = "log(\"Type A\")"];
L2 [label = "log(\"Type B\")"];
L3 [label = "log(\"Exception\")"];
NEXT [label = "next"];
BEFORE -> NEXT;
BEFORE -> T -> F -> {X_IN NORMAL_RET ERROR_RET}
NORMAL_RET -> X_OUT_NORMAL
ERROR_RET -> {C1 C2 C3}
C1 -> {X_OUT_1 L1}
C2 -> {X_OUT_2 L2}
C3 -> {X_OUT_3 L3}
}

BIN
img/catch-no-dep.pdf Normal file
View file

Binary file not shown.

16
img/catch-order.dot Normal file
View file

@ -0,0 +1,16 @@
digraph g {
ea [label="ExceptionA e"];
eb [label="ExceptionB e"];
eb1[label="ExceptionB1 e"];
eb2[label="ExceptionB2 e"];
e [label="Exception e"];
eb2 -> ea -> eb1 -> eb -> e;
EA [label="ExceptionA e"];
EB [label="ExceptionB e"];
EB1 [label="ExceptionB1 e"];
EB2 [label="ExceptionB2 e"];
E [label="Exception e"];
{EA EB} -> E;
{EB1 EB2} -> EB;
}

BIN
img/catch-order.pdf Normal file
View file

Binary file not shown.

40
img/incorrect-try-catch.dot Normal file
View file

@ -0,0 +1,40 @@
digraph g {
enter [style = filled];
mxin [label = "x = x_in", style = filled];
try [style = filled];
x_in [label = "x_in = x", style = filled];
f [label = "f()", style = filled];
nr [label = "normal return"];
x_out_nr [label = "x = x_out"];
er [label = "error return"];
catch [label = "catch (Exception e)"];
x_out_catch [label = "x = x_out"];
log [label = "log(\"error\")"];
x_0 [label = "x = 0", style = filled];
x_in2 [label = "x_in = x", style = filled];
f2 [label = "f()", style = filled];
nr2 [label = "normal return"];
er2 [label = "error return"];
ee [label = "error exit"];
x_out_nr2 [label = "x = x_out"];
x_out_ee [label = "x = x_out"];
enter -> {mxin try};
try -> f -> {x_in nr er}
nr -> x_out_nr
er -> catch -> {x_out_catch log}
enter -> {x_0 f2}
f2 -> {x_in2 nr2 er2}
nr2 -> x_out_nr2
er2 -> ee -> x_out_ee;
{edge [color = red, constraint = false];
mxin -> x_in;
x_0 -> x_in2;
}
{edge [color = blue, constraint = false];
x_in -> {x_out_nr x_out_catch}
x_in2 -> {x_out_nr2 x_out_ee}
}
}

BIN
img/incorrect-try-catch.pdf Normal file
View file

Binary file not shown.

1
paper.tex
View file

@ -15,6 +15,7 @@
\theoremstyle{definition}
\newtheorem{definition}{Definition}
\newtheorem{example}{Example}
\newtheorem{problem}{Problem}
\usepackage{hyperref}
\usepackage{graphics}
\usepackage{title/mitssTitle}