EDBT 2026 Demo / reviewers in the wild / expert
João Carlos Menezes Carreira
dblp:33/11187
· DBLP profile ↗
1ranked-venue papers
1as first author
0since 2021 · last 2012
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1 · 1 first-author
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Software testing · 67% Program analysis · 33% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Storage systems · 100% |
Topics — the 4 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing › test input generation
concolic testing |
0.1 | 1 | 2012 | Scalable testing of file system checkers · EuroSys 2012 |
Program analysis
symbolic execution |
0.1 | 1 | 2012 | Scalable testing of file system checkers · EuroSys 2012 |
Storage systems
file systems |
0.0 | 1 | 2012 | Scalable testing of file system checkers · EuroSys 2012 |
Storage systems › file systems
file system checker |
0.0 | 1 | 2012 | Scalable testing of file system checkers · EuroSys 2012 |
Methods — techniques the papers use, named apart from their topics
symbolic execution · 0.3corruption model · 0.3concrete execution · 0.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2012 | Scalable testing of file system checkersabstractFile system checkers (like e2fsck) are critical, complex, and hard to develop, and developers today rely on hand-written tests to exercise this intricate code. Test suites for file system checkers take a lot of effort to develop and require careful reasoning to cover a sufficiently comprehensive set of inputs and recovery mechanisms. We present a tool and methodology for testing file system checkers that reduces the need for a specification of the recovery process and the development of a test suite. Our methodology splits the correctness of the checker into two objectives: consistency and completeness of recovery. For each objective, we leverage either the file system checker code itself or a comparison among the outputs of multiple checkers to extract an implicit specification of correct behavior. Our methodology is embodied in a testing tool called SWIFT, which uses a mix of symbolic and concrete execution; it introduces two new techniques: a specific concretization strategy and a corruption model that leverages test suites of file system checkers. We used SWIFT to test the file system checkers of ext2, ext3, ext4, ReiserFS, and Minix; we found bugs in all checkers, including cases leading to data loss. Additionally, we automatically generated test suites achieving code coverage on par with manually constructed test suites shipped with the checkers. João Carlos Menezes Carreira, Rodrigo Rodrigues 0001, George Candea, Rupak Majumdar |
EuroSys | 1 |