Reasoning about the Node.js Event Loop using Async Graphs

Sun, Huai; Bonetta, Daniele; Schiavio, Filippo; Binder, Walter

doi:10.1109/cgo.2019.8661173

Cited by 9 publications

(7 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To deal with the limitations of static analysis for JavaScript applications, many dynamic analysis frameworks [17], [47] and tools [16], [18], [48]- [50] have been proposed. One known issue of dynamic analysis is that it can only analyze the code that is executed.…”

Section: Related Workmentioning

confidence: 99%

Automatically Assessing and Extending Code Coverage for NPM Packages

Sun

Rosà

Bonetta³

et al. 2021

2021 IEEE/ACM International Conference on Automation of Software Test (AST)

Self Cite

View full text Add to dashboard Cite

Typical Node.js applications extensively rely on packages hosted in the npm registry. As such packages may be used by thousands of other packages or applications, it is important to assess their code coverage. Moreover, increasing code coverage may help detect previously unknown issues. In this paper, we introduce TESA, a new tool that automatically assembles a test suite for any package in the npm registry. The test suite includes 1) tests written for the target package and usually hosted in its development repository, and 2) tests selected from dependent packages. The former tests allow assessing the code coverage of the target package, while the latter ones can increase code coverage by exploiting third-party tests that also exercise code in the target package. We use TESA to assess the code coverage of 500 popular npm packages. Then, we demonstrate that TESA can significantly increase code coverage by including tests from dependent packages. Finally, we show that the test suites assembled by TESA increase the effectiveness of existing dynamic program analyses to identify performance issues that are not detectable when only executing the developer's tests.

show abstract

Section: Related Workmentioning

confidence: 99%

Automatically Assessing and Extending Code Coverage for NPM Packages

Sun

Rosà

Bonetta³

et al. 2021

2021 IEEE/ACM International Conference on Automation of Software Test (AST)

Self Cite

View full text Add to dashboard Cite

show abstract

“…We use e.t to refer to the specific timeout of callback e. If e i is registered before e j , type(e i ) = type(e j ) = T and e i .t ≤ e j .t, then e i ≺ e j . If e i and e j are registered in the same tick, then under normal circumstances, the one with the smaller timeout will run first, however, there may be a long delay until it is scheduled to run, in which case the other callback will also be enabled [22]. Therefore, if e i is registered before e j (possibly in the same tick) but e i .t > e j .t, no ordering constraints exist between the two callbacks.…”

Section: B Happens-before Identification Phasementioning

confidence: 99%

“…The second bug made the test produce an HTTP 500 (Internal Server Error). 22 Basically, a request may arrive before a database-related callback is performed, causing the use of an undefined variable. For node-archiver, NODERACER uncovered a previously unknown bug; its essence is illustrated by the motivating example in Section II.…”

Section: Rq3mentioning

confidence: 99%

See 1 more Smart Citation

NodeRacer: Event Race Detection for Node.js Applications

Endo

Möller

2020

2020 IEEE 13th International Conference on Software Testing, Validation and Verification (ICST)

View full text Add to dashboard Cite

The Node.js platform empowers a huge number of software systems programmed with JavaScript. Node.js employs an asynchronous execution model where event handlers are scheduled nondeterministically, and unexpected races between event handlers often cause malfunctions. Existing techniques for detecting such event races require complex modifications of the Node.js internals, or target only certain kinds of races.This paper presents a new approach, called NODERACER, that detects event races in Node.js applications by selectively postponing events, guided by happens-before relations. The technique is implemented entirely with code instrumentation, without modifications of the Node.js system. Our experimental results give evidence that NODERACER finds event race errors with higher probability than a state-of-the-art fuzzer, and that the use of happens-before relations helps avoiding false positives. Furthermore, we demonstrate that NODERACER produces actionable error reports, and that it can be helpful for detecting test flakiness that is caused by event races.

show abstract

“…Similarly, Chrome DevTools [8] supports debugging of asynchronous stack traces by storing such information in the stack trace. Other approaches [1,18] propose a graph visualization of the state of the promise, based on run-time information about the asynchronous promise, to help developers understand the execution. The closest work is Leske et al [12] which describe an approach in which the stack of a failing promise execution is linked with the stack of the promising thread, at the point of the promise creation.…”

Section: Related Workmentioning

confidence: 99%

Framework-aware debugging with stack tailoring

Marra

Polito

Boix

2020

Proceedings of the 16th ACM SIGPLAN International Symposium on Dynamic Languages

View full text Add to dashboard Cite

Debugging applications that execute within a framework is not always easy: the call-stack offered to developers is often a mix-up of stack frames that belong to different frameworks, introducing an unnecessary noise that prevents developers from focusing on the debugging task. Moreover, relevant application code is not always available in the call-stack because it may have already returned, or is available in another thread. In such cases, manually gathering all relevant information from these different sources is not only cumbersome but also costly.In this paper we introduce Sarto, a call-stack instrumentation layer that allows developers to tailor the stack to make debugging framework-aware. The goal is to improve the quality and amount information present in the call-stack to reduce debugging time without impacting the execution time. Sarto proposes a set of six stack operations that combined hide irrelevant information, introduce missing information, and relate dispersed debugging sources before this is fed to the debugger.We validate Sarto by applying it to four application cases using inherently different frameworks: unit testing, web server, remote promises and big data processing. We showcase our experiences in using Sarto in the different frameworks, and perform some performance benchmarks to demonstrate that Sarto does not generate noticeable overhead when instrumenting a call-stack. We also show that our solution reduces by half the amount of data stored to debug similar exceptions happening in a parallel setup.CCS Concepts: • Software and its engineering → Application specific development environments; Integrated and visual development environments; Error handling and recovery; Software testing and debugging.

show abstract

Reasoning about the Node.js Event Loop using Async Graphs

Cited by 9 publications

References 15 publications

Automatically Assessing and Extending Code Coverage for NPM Packages

Automatically Assessing and Extending Code Coverage for NPM Packages

NodeRacer: Event Race Detection for Node.js Applications

Framework-aware debugging with stack tailoring

Contact Info

Product

Resources

About