Results 1 -
9 of
9
Tolerating Memory Leaks
- In ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications
, 2008
"... Abstract Type safety and garbage collection in managed languages elimi-nate memory errors such as dangling pointers, double frees, and ..."
Abstract
-
Cited by 12 (4 self)
- Add to MetaCart
Abstract Type safety and garbage collection in managed languages elimi-nate memory errors such as dangling pointers, double frees, and
Leak Pruning
- ASPLOS'09
, 2009
"... Managed languages improve programmer productivity with type safety and garbage collection, which eliminate memory errors such as dangling pointers, double frees, and buffer overflows. However, programs may still leak memory if programmers forget to eliminate the last reference to an object that will ..."
Abstract
-
Cited by 8 (4 self)
- Add to MetaCart
Managed languages improve programmer productivity with type safety and garbage collection, which eliminate memory errors such as dangling pointers, double frees, and buffer overflows. However, programs may still leak memory if programmers forget to eliminate the last reference to an object that will not be used again. Leaks slow programs by increasing collector workload and frequency. Growing leaks crash programs. Instead of crashing, leak pruning extends program availability by predicting and reclaiming leaked objects at run time. Whereas garbage collection over-approximates live objects using reachability, leak pruning predicts dead objects and reclaims them based on how stale they are and the size of stale data structures. Leak pruning preserves semantics because it waits for heap exhaustion before reclaiming objects and then poisons references to objects it reclaims. If the program later tries to access these objects, the virtual machine (VM) throws an internal error. We implement leak pruning in a Java VM, show its overhead is low, and evaluate it on 10 leaking programs. Leak pruning does not help two programs, executes four substantial programs 1.6-35X longer, and executes four programs, including two leaks in Eclipse, for at least 24 hours. In the worst case, leak pruning defers fatal errors. In the best case, programs with unbounded memory requirements execute indefinitely and correctly in bounded memory with consistent throughput.
Efficiently and precisely locating memory leaks and bloat
- Conference on Programming Language Design and Implementation
, 2009
"... Inefficient use of memory, including leaks and bloat, remain a significant challenge for C and C++ developers. Applications with these problems become slower over time as their working set grows and can become unresponsive. At the same time, memory leaks and bloat remain notoriously difficult to deb ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
Inefficient use of memory, including leaks and bloat, remain a significant challenge for C and C++ developers. Applications with these problems become slower over time as their working set grows and can become unresponsive. At the same time, memory leaks and bloat remain notoriously difficult to debug, and comprise a large number of reported bugs in mature applications. Previous tools for diagnosing memory inefficiencies—based on garbage collection, binary rewriting, or code sampling—impose high overheads (up to 100X) or generate many false alarms. This paper presents Hound, a runtime system that helps track down the sources of memory leaks and bloat in C and C++ applications. Hound employs data sampling, a staleness-tracking approach based on a novel heap organization, to make it both precise and efficient. Hound has no false positives, and its runtime and space overhead are low enough that it can be used in deployed applications. We demonstrate Hound’s efficacy across a suite of synthetic benchmarks and real applications.
First-aid: surviving and preventing memory management bugs during production runs
- Proceedings of the 4 th European Conference on Computer System
, 2009
"... Memory bugs in C/C++ programs severely affect system availability and security. This paper presents First-Aid, a lightweight runtime system that survives software failures caused by common memory management bugs and prevents future failures by the same bugs during production runs. Upon a failure, Fi ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
Memory bugs in C/C++ programs severely affect system availability and security. This paper presents First-Aid, a lightweight runtime system that survives software failures caused by common memory management bugs and prevents future failures by the same bugs during production runs. Upon a failure, First-Aid diagnoses the bug type and identifies the memory objects that trigger the bug. To do so, it rolls back the program to previous checkpoints and uses two types of environmental changes that can prevent or expose memory bug manifestation during re-execution. Based on the diagnosis, First-Aid generates and applies runtime patches to avoid the memory bug and prevent its reoccurrence. Furthermore, First-Aid validates the consistent effects of the runtime patches and generates on-site diagnostic reports to assist developers in fixing the bugs. We have implemented First-Aid on Linux and evaluated it with seven applications that contain various types of memory bugs, including buffer overflow, uninitialized read, dangling pointer read/write, and double free. The results show that First-Aid can quickly diagnose the tested bugs and recover applications from failures (in 0.084 to 3.978 seconds). The results also show that the runtime patches generated by First-Aid can prevent future failures caused by the diagnosed bugs. Additionally, First-Aid provides detailed diagnostic information on both the root cause and the manifestation of the bugs. Furthermore, First-Aid incurs low overhead (0.4-11.6 % with an average of 3.7%) during normal execution for the tested buggy applications, SPEC INT2000, and four allocation intensive programs.
Diagnosing and Tolerating Bugs in Deployed Systems Committee:
, 2008
"... I am deeply grateful to Kathryn McKinley for supporting and mentor-ing me in many ways. Kathryn has provided invaluable technical expertise and feedback even as we worked in new areas. She has been unwaveringly enthusiastic and positive about students and ideas and projects, and she has been a stron ..."
Abstract
- Add to MetaCart
I am deeply grateful to Kathryn McKinley for supporting and mentor-ing me in many ways. Kathryn has provided invaluable technical expertise and feedback even as we worked in new areas. She has been unwaveringly enthusiastic and positive about students and ideas and projects, and she has been a strong advocate, putting my and other students ’ interests first. I en-tered graduate school uncertain about getting a Ph.D., and I leave inspired to pursue an academic career because of Kathryn. Steve Blackburn has been an enthusiastic supporter and has devoted a lot of his time to solving problems and giving advice, both solicited and unso-licited. Steve, Keshav Pingali, Peter Stone, and Emmett Witchel have given helpful feedback and spent a lot of time reading long documents and attending long talks. Vitaly Shmatikov and Steve Keckler have provided valuable advice and mentoring. David Padua and Craig Zilles were supportive advisors when I was a master’s student at the University of Ilinois. The graduate student community at UT has been incredibly support-ive. I am thankful to have Ben Wiedermann, Xianglong Huang, and Milind Kulkarni as friends and colleagues. I am indebted to them and to the fol-lowing friends and colleagues for their technical and personal support: Kar-
Emmett WitchelDiagnosing and Tolerating Bugs in Deployed Systems Acknowledgments
, 2008
"... Committee: Copyright by ..."
Diagnosing and Tolerating Bugs in Deployed Systems Acknowledgments Diagnosing and Tolerating Bugs in Deployed Systems
, 2008
"... by ..."
LeakChaser: Helping Programmers Narrow Down Causes of Memory Leaks
"... In large programs written in managed languages such as Java and C#, holding unnecessary references often results in memory leaks and bloat, degrading significantly their run-time performance and scalability. Despite the existence of many leak detectors for such languages, these detectors often targe ..."
Abstract
- Add to MetaCart
In large programs written in managed languages such as Java and C#, holding unnecessary references often results in memory leaks and bloat, degrading significantly their run-time performance and scalability. Despite the existence of many leak detectors for such languages, these detectors often target low-level objects; as a result, their reports contain many false warnings and lack sufficient semantic information to help diagnose problems. This paper introduces a specification-based technique called LeakChaser that can not only capture precisely the unnecessary references leading to leaks, but also explain, with high-level semantics, why these references become unnecessary. At the heart of LeakChaser is a three-tier approach that uses varying levels of abstraction to assist programmers with different skill levels and code familiarity to find leaks. At the highest tier

