EventHealer: Bypassing data races in event-driven programs

Tchamgoue, Guy Martin; Kim, Kyong Hoon; Jun, Yong-Kee

doi:10.1016/j.jss.2016.02.051

Cited by 3 publications

(3 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…C Assume the user clicks the "Gallery 1" button after the entire page has been parsed. This causes loadThumbs (lines [15][16][17][18][19][20][21][22][23][24][25][26] to execute with argument "g1," generating an Ajax request. When the server responds, the event handler on lines 18-23 executes, causing showThumbs to execute (lines 27-40).…”

Section: A Event Racesmentioning

confidence: 99%

“…EventHealer [26], unlike most of the work mentioned above, considers event-driven programs, but with a different execution model than the one in JavaScript: execution takes place in a main thread, which has lower priority than event handlers, and preemption is possible but can be selectively disabled to protect critical sections. The system uses static analysis to locate event handlers, shared variables, and fragments of code that should be treated as critical sections, which is very different from our setting.…”

Section: Related Workmentioning

confidence: 99%

“…File index.html defines a top-level page with two buttons, labeled "Gallery 1" and "Gallery 2." Clicking each button causes function loadThumbs (lines [15][16][17][18][19][20][21][22][23][24][25][26] to be invoked with the gallery name "g1" or "g2," depending on the gallery being selected. Executing loadThumbs will send an Ajax request to the server (lines [17][18][19][20][21][22][23][24][25].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Repairing Event Race Errors by Controlling Nondeterminism

Adamsen

Möller

Karim

et al. 2017

2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE)

View full text Add to dashboard Cite

Modern web applications are written in an eventdriven style, in which event handlers execute asynchronously in response to user or system events. The nondeterminism arising from this programming style can lead to pernicious errors. Recent work focuses on detecting event races and classifying them as harmful or harmless. However, since modifying the source code to prevent harmful races can be a difficult and error-prone task, it may be preferable to steer away from the bad executions. In this paper, we present a technique for automated repair of event race errors in JavaScript web applications. Our approach relies on an event controller that restricts event handler scheduling in the browser according to a specified repair policy, by intercepting and carefully postponing or discarding selected events. We have implemented the technique in a tool called EventRaceCommander, which relies entirely on source code instrumentation, and evaluated it by repairing more than 100 event race errors that occur in the web applications from the largest 20 of the Fortune 500 companies. Our results show that applicationindependent repair policies usually suffice to repair event race errors without excessive negative impact on performance or user experience, though application-specific repair policies that target specific event races are sometimes desirable.

show abstract