Automatic detection and repair of errors in data structures

Demsky, Brian; Rinard, Martin

doi:10.1145/949305.949314

Cited by 118 publications

(50 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Finally, data structure repair approaches have a goal similar to that of the approach proposed in this paper-the regeneration of a portion of an invalid data structure instance (by relying upon ad hoc search [Demsky and Rinard 2003], by using symbolic execution [Elkarablieh et al 2007], or SAT solving [Nokhbeh Zaeem et al 2012]). For example, Cobbler generates an Alloy model that captures the content of an invalid data structure along with its invariants and method post-conditions, and then uses Alloy to reassigning the data structure fields that appear in the Alloy subformulas and are not satisfied by the invalid data [Nokhbeh Zaeem et al 2012].…”

Section: Related Workmentioning

confidence: 99%

Augmenting Field Data for Testing Systems Subject to Incremental Requirements Changes

Nardo

Pastore

Briand

2017

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

When testing data processing systems, software engineers often use real world data to perform system level testing. However, in the presence of new data requirements software engineers may no longer benefit from having real world data with which to perform testing. Typically, new test inputs complying with the new requirements have to be manually written.We propose an automated model-based approach that combines data modelling and constraint solving to modify existing field data to generate test inputs for testing new data requirements. The approach scales in the presence of complex and structured data, thanks to both the reuse of existing field data and the adoption of an innovative input generation algorithm based on slicing the model into parts.We validated the scalability and effectiveness of the proposed approach using an industrial case study. The empirical study shows that the approach scales in the presence of large amounts of structured and complex data. The approach can produce, within a reasonable time, test input data that is over ten times larger in size than the data generated with constraint solving only. We also demonstrate that the generated test inputs achieve more code coverage than the test cases implemented by experienced software engineers.

show abstract

Section: Related Workmentioning

confidence: 99%

Augmenting Field Data for Testing Systems Subject to Incremental Requirements Changes

Nardo

Pastore

Briand

2017

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

show abstract

“…While the contents of the stack can be recovered by restoring the stack pointer, special care must be placed in handling the state of the heap. To deal with data corruption in the heap, we can employ data structure consistency constraints, as described in [24], to detect and recover from such errors. Thus, the code in our example from Fig.…”

Section: Recovery: Execution Transactionsmentioning

confidence: 99%

“…Our experimental evaluation through a benchmark suite, which issues many thousand requests to the same application, gives us some confidence that their internal state does not "decay" quickly. To address longer-term deterioration, we can use either micro-rebooting (software rejuvenation) [11] or automated data-structure repair [24]. We intend to examine the combination of our approach with either of these techniques in future work.…”

Section: Execution Transaction Validationmentioning

confidence: 99%

“…An important contribution in this area is [25], which discusses mechanisms for detecting corrupted data structures and fixing them to match some pre-specified constraints. While the precision of the fixes with respect to the semantics of the program is not guaranteed, their test cases continued to operate when faults were randomly injected.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Execution transactions for defending against software failures: use and evaluation

Sidiroglou

Keromytis

2006

Int. J. Inf. Secur.

View full text Add to dashboard Cite

We examine the problem of containing buffer overflow attacks in a safe and efficient manner. Briefly, we automatically augment source code to dynamically catch stack and heap-based buffer overflow and underflow attacks, and recover from them by allowing the program to continue execution. Our hypothesis is that we can treat each code function as a transaction that can be aborted when an attack is detected, without affecting the application's ability to correctly execute. Our approach allows us to enable selectively or disable components of this defensive mechanism in response to external events, allowing for a direct tradeoff between security and performance. We combine our defensive mechanism with a honeypot-like configuration to detect previously unknown attacks, automatically adapt an application's defensive posture at a negligible performance cost, and help determine worm signatures. Our scheme provides low impact on application performance, the ability to respond to attacks without human intervention, the capacity to handle previously unknown vulnerabilities, and the preservation of service availability. We implement a stand-alone tool, DYBOC, which we use to instrument a number of vulnerable applications. Our performance benchmarks indicate a slow-down of 20% for Apache in full-protection mode, and 1.2% with selective protection. We provide preliminary evidence toward the validity of our transactional hypothesis via two experiments: first, by applying our scheme to 17 vulnerable applications, successfully fixing 14 of them; second, by examining the behavior of Apache when each of 154 potentially vulnerable routines are made to fail, resulting in correct behavior in 139 cases (90%), with similar results for sshd (89%) and Bind (88%).

show abstract

“…Instrumentation techniques are widely applied in selfhealing systems, such as detecting faults, repairing failures [8,6], and enforcing policies [9]. In a general instrumentation framework [10], a instrumentation ''recipe'' is required to indicate what to monitor.…”

Section: Introductionmentioning

confidence: 99%