As fuzz testing has passed its 30th anniversary, and in the face of the incredible progress in fuzz testing techniques and tools, the question arises if the classic, basic fuzz technique is still useful and applicable? In that tradition, we have updated the basic fuzz tools and testing scripts and applied them to a large collection of Unix utilities on Linux, FreeBSD, and MacOS. As before, our failure criteria was whether the program crashed or hung. We found that 9 crash or hang out of 74 utilities on Linux, 15 out of 78 utilities on FreeBSD, and 12 out of 76 utilities on MacOS. A total of 24 different utilities failed across the three platforms. We note that these failure rates are somewhat higher than our in previous 1995, 2000, and 2006 studies of the reliability of command line utilities. In the basic fuzz tradition, we debugged each failed utility and categorized the causes the failures. Classic categories of failures, such as pointer and array errors and not checking return codes, were still broadly present in the current results. In addition, we found a couple of new categories of failures appearing. We present examples of these failures to illustrate the programming practices that allowed them to happen. As a side note, we tested the limited number of utilities available in a modern programming language (Rust) and found them to be of no better reliability than the standard ones.

Compute node failures are becoming a normal event for many long-running and scalable MPI applications. Keeping within the MPI standards and applying some of the methods developed so far in terms of fault tolerance, we developed a methodology that allows applications to tolerate failures through the creation of semi-coordinated checkpoints within the RADIC architecture. To do this, we developed the ULSC2-RADIC middleware that divides the application into independent MPI worlds where each MPI world would correspond to a compute node and make use of the DMTCP checkpoint library in a semi-coordinated environment. We performed experimental results using scientific applications and the NAS Parallel Benchmarks to assess the overhead and also the functionality in case of a node failure. We evaluated the computational cost of the semi-coordinated checkpoints compared with the coordinated checkpoints.

Software assurance tools – tools that scan the source or binary code of a program to find weaknesses – are the first line of defense in assessing the security of a software project. Even though there are a plethora of such tools available, with multiple tools for almost every programming language, adoption of these tools is spotty at best. And even though different tools have distinct abilities to find different kinds of weaknesses, the use of multiple tools is even less common. And when the tools are used (or attempted to be used), they are often used in ways that reduce their effectiveness. We present a step-by-step discussion of how to use a software assurance tool, describing the challenges that can occur in this process. We also present quantitative evidence about the effects that can occur when assurance tools are applied in a simplistic or naive way. We base this presentation on our direct experiences with using a wide variety of assurance tools. We then present the US Department of Homeland Security funded Software Assurance Marketplace (SWAMP), an open facility where users can upload their software to have it automatically and continually assessed by a variety of tools. The goal of the SWAMP is to simplify the task of the programmer in using assurance tools, thereby removing many of the obstacles to their adoption. Copyright © 2016 The Authors. Software: Practice and Experience Published by John Wiley & Sons, Ltd.

Nowadays distributed applications, including MPI implementations, are executed on computer clusters managed by a batch queue system. Users take advantage of monitoring tools to detect run-time problems on their applications running on those environments. But it is a challenge to use monitoring tools on a cluster controlled by a batch queue system. This is due to the fact that batch queue systems and monitoring tools do not coordinate the management of the resources they share, when executing a distributed application. We name this problem lack of interoperability and to solve it we have developed a framework called TDP-Shell. This framework supports different batch queue systems such as Condor and SGE, and different monitoring tools such as Paradyn, Gdb and Total view, without any changes on their source code. In this paper we describe how our basic design of TDP-Shell for sequential applications was re-designed to support the monitoring of MPI applications that are executed on a cluster controlled by a batch queue system.

Workflow applications exhibit both high computation times and data transfer rates. For this reason, the completion time of the workflow is high. To reduce completion time, the tasks of a workflow ought to run on different machines interconnected by a network. Correct assignment of tasks to machines within the runtime environment is an important aspect in the completion time or make span. The manager making the assignment is the scheduler. The main problem of a static scheduler is that it ignores the changes that occur in the execution environment during DAG execution. To solve this problem, we developed a new dynamic scheduler. This dynamic scheduler monitors the behavior of the tasks executed as well as the execution environment, and it reacts to the changes detected by adapting the scheduling of the rest of pending tasks. The objective is to reduce the overhead incurred by excessive self-adaptations, without affecting the make span. To reduce overhead, the algorithm self-adapts only when an improvement in make span is expected. The proposed policies have been simulated and then executed in a real environment. These executions have achieved a reduction of the overhead of greater than 20%.

A fundamental problem in large scale Grids is the need for efficient and scalable techniques for resource discovery and scheduling. In traditional resource scheduling systems a single scheduler handles information about all computing resources and schedules jobs. This centralized approach has a serious scalability problem, since it introduces a bottleneck, as well as a single point of failure. Some decentralized scheduling systems have been proposed to improve scalability. However, the main contributions in this area are generally carried out under the assumption of several coordinated schedulers. Nevertheless this approach leads to high communication costs. Such costs are mainly caused by the strong dependency on negotiation among scheduler-to-scheduler and scheduler-to-resource communication. Current approaches to decentralized resource management - in particularly approaches based on Random Early Detection (RED) - are non-coordinated since these schedulers make scheduling related decisions in an independent way. This paper introduces a collaborative model of decentralized scheduling that improves resource scheduling based on RED strategies via gossiping. With this approach, schedulers can receive information from other schedulers without creating a high communication overhead and continue scheduling jobs in an independent way. The simulation results shows that our proposal is scalable and it handles large resources efficiently on large scale Grids.

Most recent grid middleware technologies have been aimed at the execution of sequential batch jobs. However, some users require interactive access when running jobs on grid sites. Execution of these applications on a grid environment is a challenging problem that requires the cooperation of several middleware tools and services. Additional problems arise when this interactive support is intended for parallel applications, which may run remotely across several sites. We provide transparent and reliable support for such applications. Our solution, based on the notion of split execution and interposition agents, allows running applications on a remote machine while some I/O operations are sent back to a home machine. The paper describes how we have applied interposition agents transparently to interactive applications and also describes a simple multiprogramming mechanism that is used to start interactive applications as fast as possible even under heavy occupancy of resources. We provide a performance evaluation of the key elements involved in the execution of interactive jobs

Scheduling is an important factor for the efficient execution of computational workflows on grid environments. A large number of static scheduling heuristics has been presented in the literature. These algorithms allocate tasks before job execution starts and assume a precise knowledge of timing information, which may be difficult to obtain in general. To overcome this limitation of static strategies, dynamic scheduling strategies may be needed for a changing environment such as the grid. While they incur runtime overheads, they may better adapt to timing changes during job execution. In this work, we analyse five well-known heuristics (min-min, max-min, sufferage, HEFT and random) when used as static and dynamic scheduling strategies in a grid environment in which computing resources exhibit congruent performance differences. The analysis shows that non-list based heuristics are more sensitive than list-based heuristics to inaccuracies in timing information. Static list-based heuristics perform well in the presence of low or moderate inaccuracies. Dynamic versions of these heuristics may be needed only in environments where high inaccuracies are observed. Our analysis also shows that list-based heuristics significantly outperform non-list based heuristics in all cases and, therefore, constitute the most suitable strategies by which to schedule workflows either statically or dynamically

We investigate the scheduling problem that arises in parallel applications executing on a network of machines by using a mode of cycle-stealing. In this mode of execution a parallel application executes its tasks in several machines whenever they are idle. When the user reclaims the machine, tasks must relinquish control immediately. In this case, the parallel application has the risk of losing work in progress on reclaimed machines and, therefore, the total execution time of the parallel application will be affected by the need for rescheduling the pre-empted task. We first evaluate the impact on the performance of an application when it runs on two different scenarios: a set of N dedicated machines, and a set of N non-dedicated machines (in which pre-emption may occur). This study shows that losing machines may have a considerable impact on the execution time of the application and therefore, we propose and evaluate three simple strategies to alleviate this problem. All strategies are based on the use of additional machines, but they differ in the way that these extra machines are used. In the first strategy additional machines are added to the common pool of machines used by the application. The other two are based on task replication, in which the additional machines are used to execute certain tasks that are already running in other machines.