background.tex

\section{what is an Environment?}
\label{SEC:background}

It is important
to have a clear understanding
of what constitutes an application's environment
in order to see how it can contribute to the presence of bugs.
An application's environment consists of
all of the components an application depends upon
that its developers do not control.
In practice, this is everything other than the code and data packaged
within the application itself.
Typically testers
focus on explicit inputs to the application
and overlook the implicit inputs
coming from these uncontrolled components.

Anything external to the application can be
configured in unexpected ways.
For example, library search rules can result in default system libraries
being loaded instead of
the versions deployed alongside the application.
These external resources can be thought of as
providing implicit inputs to the program that affect its flow of execution.
An investigation of bug reports has shown that environmental bugs in the
following categories have been found in major applications.

\begin{itemize}

\item {\bf Operating Systems.} Differences in the way operating systems
implement system calls can influence the behavior of applications.  For
example, on Linux it is possible to remove an open file, yet this is not
allowed on Windows systems~\cite{UnlinkStandard}.  An application
written without this difference in mind could fail if it relies on one
implementation or the other.

\item {\bf File Systems.}  The exact file system used will also have a
substantial impact on the behavior of a system, independent of the
operating system.  The popular Ext4 file system on Linux is case sensitive,
so that ``a'' and ``A'' are different files,
while in OS X's HFS+ file system
those file names would refer to the same file.
File systems can have varying limits or behaviors for other items as well,
including file name length (popularized due to the 8.3 limitations of the
FAT file system), maximum file length, number of directory entries, or
depth
of directories supported, all of which can lead to errors when programs
do not account for these variations~\cite{EXT4Layout, AppleHFS}.
The layout and contents of a filesystem can also impact an application's
execution.  Unexpected file types can result in application
failures, and multi-disk layouts impose additional requirements on
common operations, such as moving a file from one location to
another.
        We explore the latter two situations in our
        evaluation (Sec.~\ref{sec-env-bugs}).

\item {\bf Network.} Both local and remote network nodes
can have specific characteristics that could influence the behavior of an
application.
For example, POSIX operating
systems support the notion of limiting the kernel buffer set aside for a
socket.  However, many other popular operating
systems (Windows, Linux, and Mac)
implement this quite differently.
If a UDP datagram
larger than the specified buffer size is received by a Linux system,
it will be dropped.
Windows,
however,
will receive these datagrams,
but it will influence data retrieval.
Any system calls that retrieve data from the buffer in which
datagrams are
stored will only return a number of bytes less than or equal to the
buffer size, requiring multiple calls
to retrieve all the data.~\cite{Zhuang_NSDI_2014}.

\item {\bf Processor.}  The processor used can also influence the
behavior of an application.  This is frequently
evidenced through the different floating point behaviors a
processor may exhibit~\cite{ArbitraryPrecision}.
In addition, bugs are fairly common
in processors and will cause variances, as will
differences in interpreting
how to execute complex instructions~\cite{Microarch}.

\end{itemize}

In this work, we chose to focus on operating system,
file system, and network
environmental issues.
These issues are
readily visible in data returned
by the system calls
an application makes.
We took advantage of this in our implementation of SEA as CrashSimulator by
intercepting and manipulating system call results.
As we will discuss, this allowed us to strike a good balance between a
higher level approach, such as hooking library functions, and a lower level
approach like directly altering memory values.
In our evaluation we take a deeper look at anomalies from
these three categories in order to assess the technique's effectiveness.
We do not consider processor-based environmental differences as bugs related to those are being handled by other
work~\cite{Alglave:2018:FSC:3173162.3177156}.