A type-and-effect system for asynchronous, typed events

Implicit concurrency between handlers is important for event driven systems because it helps simultaneously promote modularity and scalability. Knowing the side-effect of the handlers is critical in these systems to avoid concurrency hazards such as data races. As event systems are dynamic because statically known and unknown handlers can register at almost any time during program execution, static effect analyses must reconcile over competing goals such as precision, soundness and modularity. We recently developed asynchronous, typed events, a system that can analyze the effects of the handlers at runtime. This mechanism utilizes runtime information to enable precise effect computation and greatly improves concurrency between handlers. In this paper, we present the formal underpinnings of asynchronous, typed events, and examine the concurrency safety properties it provides. The technical innovations of our system include a novel effect system to soundly approximate the dynamism introduced by runtime handlers registration, a static analysis to precompute the effects and a dynamic analysis that uses the precomputed effects to improve concurrency. Our design simplifies modular concurrency reasoning and avoids concurrency hazards

Efficiently Manifesting Asynchronous Programming Errors in Android Apps

Android, the #1 mobile app framework, enforces the single-GUI-thread model, in which a single UI thread manages GUI rendering and event dispatching. Due to this model, it is vital to avoid blocking the UI thread for responsiveness. One common practice is to offload long-running tasks into async threads. To achieve this, Android provides various async programming constructs, and leaves developers themselves to obey the rules implied by the model. However, as our study reveals, more than 25% apps violate these rules and introduce hard-to-detect, fail-stop errors, which we term as aysnc programming errors (APEs). To this end, this paper introduces APEChecker, a technique to automatically and efficiently manifest APEs. The key idea is to characterize APEs as specific fault patterns, and synergistically combine static analysis and dynamic UI exploration to detect and verify such errors. Among the 40 real-world Android apps, APEChecker unveils and processes 61 APEs, of which 51 are confirmed (83.6% hit rate). Specifically, APEChecker detects 3X more APEs than the state-of-art testing tools (Monkey, Sapienz and Stoat), and reduces testing time from half an hour to a few minutes. On a specific type of APEs, APEChecker confirms 5X more errors than the data race detection tool, EventRacer, with very few false alarms

Detecting Feature-Interaction Symptoms in Automotive Software Using Lightweight Analysis

Copyright (c) 2019 IEEE Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Modern automotive software systems are large, com- plex, and feature rich; they can contain over 100 million lines of code, comprising hundreds of features distributed across multiple electronic control units (ECUs), all operating in parallel and communicating over a CAN bus. Because they are safety-critical systems, the problem of possible Feature Interactions (FIs) must be addressed seriously; however, traditional detection approaches using dynamic analyses are unlikely to scale to the size of these systems. We are investigating an approach that detects static source-code patterns that are symptomatic of FIs. The tools report Feature-Interaction warnings, which can be investigated further by engineers to determine if they represent true FIs and if those FIs are problematic. In this paper, we present our preliminary toolchain for FI detection. First, we extract a collection of static “facts” from the source code, such as function calls, variable assignments, and messages between features. Next, we perform relational algebra transformations on this factbase to infer additional “facts” that represent more complicated design information about the code, such as potential information flows and data dependencies; then, the full collection of “facts” is matched against a curated set of patterns for FI symptoms. We present a set of five patterns for FIs in automotive software as well a case study in which we applied our tools to the Autonomoose autonomous-driving software, developed at the University of Waterloo. Our approach identified 1,444 possible FIs in this codebase, of which 10% were classified as being probable interactions worthy of further investigation.General Motors Research Project, GAC 2453 Ontario Research Fund, RE05-04

Detecting Feature-Interaction Hotspots in Automotive Software using Relational Algebra

Modern software projects are programmed by multiple teams, consist of millions of lines of code, and are split into separate components that, during runtime, may not be contained in the same process. Due to these complexities, software defects are a common reality; defects cost the global economy over a trillion dollars each year. One area where developing safe software is crucial is the automotive domain. As the typical modern vehicle consists of over 100 million lines of code and is responsible for controlling vehicle motion through advanced driver-assistance systems (ADAS), there is a potential for these systems to malfunction in catastrophic ways. Due to this risk, automotive software needs to be inspected to verify that it is safe. The problem is that it can be difficult to carry out this detection in code; manual analysis does not scale well, search tools like grep have no contextual awareness of code, and although code reviews can be effective, they cannot target the entire codebase properly. Furthermore, automotive systems are comprised of numerous, communicating features that can possibly interact in unexpected or undefined ways. This thesis addresses this problem through the development of a static-analysis methodology that detects custom interaction patterns coined as hotspots. We identify several classes of automotive hotspots that describe patterns in automotive software that have the possibility of manifesting as a feature interaction. To detect these hotspots, this methodology employs a static, relational analysis toolchain that create a queryable model from source code and enable engineer defined queries to be run on the model that aim to reveal potential hotspots in the underlying source code. The purpose of this methodology is not to detect bugs with surety but work towards an analysis methodology that can scale to automotive software systems. We test this hotspot detection methodology through a case study conducted on the Autonomoose autonomous driving platform. In it, we generate a model of the entire Autonomoose codebase and run relational algebra queries on the model. Each script in the case study detects a type of hotspot we identify in this thesis. The results of each query are presented