Detecting Concurrency Errors in Client-Side Java Script Web Applications

Abstract

As web technologies have evolved, the complexity of dynamic web applications has increased significantly and web applications suffer concurrency errors due to unexpected orders of interactions among web browsers, users, the network, and so forth. In this paper, we present WAVE (Web Application's Virtual Environment), a testing framework to detect concurrency errors in client-side web applications written in JavaScript. WAVE generates various sequences of operations as test cases for a web application and executes a sequence of operations by dynamically controlling interactions of a target web application with the execution environment. We demonstrate that WAVE is effective and efficient for detecting concurrency errors through experiments on eight examples and five non-trivial real-world web applications.

Stateless model checking of event-driven applications

“…We evaluate the effectiveness of R 4 compared to state of the art systems for finding concurrency bugs in real-world web pages: EVENTRACER [27] and WAVE [12]. We also evaluate the use of conflict-reversal bounding and partial order reduction.…”

“…That situa-tion is particularly likely in an event-driven setting where the event handlers are not just simple read and write transitions but are complex operations that often use ad-hoc synchronization [27], similar to the timeout in our running example. Prior work, both in standard shared memory [24] and in event-driven applications [12] essentially ignores this phenomenon.…”

“…In our evaluation, we operate on substantially longer event sequences. The recordings contain 3 742 events on average, while Hong et al [12] report on sequences averaging only 7.2 events, due to lacking any happens-before information, ignoring events at page-load time, and targeting only specific interaction scenarios. To ensure a fair comparison, we therefore compare R 4 with an algorithm that samples traces in a manner similar to WAVE as follows: (1) generate x copies of the recorded event sequence, where x is the number of explored events in the original recorded sequence; (2) swap multiple random pairs of events in each event sequence if allowed by the happens-before relation; (3) execute each resulting event sequence, and apply the same detectors for erroneous event sequences as WAVE: DOM state differences, existence of uncaught exceptions, and inability to execute an event sequence.…”

“…These capabilities can be used for a range of bug detection scenarios. For example, we can use them to check for common issues, such as, harmfulness of conflicts, application crashes, assertion failures, and output discrepancies (e.g., [8,12,15,20,29]). …”

“…Indeed, despite filtering techniques, state-of-the-art analyzers, such as EVENTRACER [27], report too many false positives. Approaches that do explore more than one schedule, including WAVE [12], suffer from serious drawbacks: first, they do not detect interference and thus may keep exploring equivalent schedules; second, they are inherently unable to report the primary cause of the nondeterminism (making it difficult to fix errors), and finally, they provide no meaningful guarantees on the explored schedules.…”