Crash Data Collection: A Windows Case Study

Ganapathi, Archana; Patterson, David A.

doi:10.1109/dsn.2005.32

Cited by 34 publications

(27 citation statements)

References 10 publications

(10 reference statements)

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…There is however scant empirical evidence regarding API design and implementation guidelines; published articles focus on general practices (Bloch 2006;Henning 2009;Tulach 2012). In addition, although there is a body of research on bug characterization (Li et al 2006;Guo et al 2010;Tan et al 2013) and crash analysis (Ganapathi et al 2006;Ganapathi and Patterson 2005;Kim et al 2011a), to the best of our knowledge, there is no study that attributes crash causes to API deficiencies. The main two contributions of this paper are: a) a method that links telemetry data from application crashes to API calls, and b) the use of this method to identify API weaknesses that can lead to execution failures.…”

Section: Introductionmentioning

confidence: 92%

Charting the API minefield using software telemetry data

2014

View full text Add to dashboard Cite

Programs draw significant parts of their functionality through the use of Application Programming Interfaces (APIs). Apart from the way developers incorporate APIs in their software, the stability of these programs depends on the design and implementation of the APIs. In this work, we report how we used software telemetry data to analyze the causes of API failures in Android applications. Specifically, we got 4.9 GB worth of crash data that thousands of applications sent to a centralized crash report management service. We processed that data to extract approximately a million stack traces, stitching together parts of chained exceptions, and established heuristic rules to draw the border between applications and the API calls. We examined a set of more than a half million stack traces associated with risky API calls to map the space of the most common application failure reasons. Our findings show that the top ones can be attributed to memory exhaustion, race conditions or deadlocks, and missing or corrupt resources. Given the classes of the crash causes we identified, we recommend API design and implementation choices, such as specific exceptions, default resources, and non-blocking algorithms, that can eliminate common failures. In addition, we argue that development tools like memory analyzers, thread debuggers, and static analyzers can prevent crashes through early code testing and analysis. Finally, some execution platform and framework designs for process and memory management can also eliminate some application crashes.

show abstract

Section: Introductionmentioning

confidence: 92%

Charting the API minefield using software telemetry data

2014

View full text Add to dashboard Cite

show abstract

“…They found that most OS crashes are caused by poorly written device drivers. Several reliability monitoring approaches have been proposed that help to collect crashes from the field [17,28]. In addition, capture and replay techniques can locate failures, reproduce crashes, and monitor the performance of a system [5,10,11,18,22,24,38,47].…”

Section: Related Workmentioning

confidence: 99%

Predicting method crashes with bytecode operations

Kim

Zimmermann

Premraj³

et al. 2013

Proceedings of the 6th India Software Engineering Conference

View full text Add to dashboard Cite

Software monitoring systems have high performance overhead because they typically monitor all processes of the running program. For example, to capture and replay crashes, most current systems monitor all methods; thus yielding a significant performance overhead. Lowering the number of methods being monitored to a smaller subset can dramatically reduce this overhead. We present an approach that can help arrive at such a subset by reliably identifying methods that are the most likely candidates to crash in a future execution of the software. Our approach involves learning patterns from features of methods that previously crashed to classify new methods as crash-prone or non-crash-prone. An evaluation of our approach on two large open source projects, ASPECTJ and ECLIPSE, shows that we can correctly classify crash-prone methods with an accuracy of 80-86%. Notably, we found that the classification models can also be used for cross-project prediction with virtually no loss in classification accuracy. In a further experiment, we demonstrate how a monitoring tool, RECRASH could take advantage of only monitoring crash-prone methods and thereby, reduce its performance overhead and maintain its ability to perform its intended tasks.

show abstract

“…Time and spatial coalescence techniques have been applied to a variety of large scale computing systems [2], [3], [5]- [8], [11], [16], [20], [25], [26]. The common trend is to use tupling with a fixed value for time window, such as 5 minutes [1], [3], [6]- [8], [27], [28], 20 minutes [9], [10], [12], and 60 minutes [12], [13], usually without any tuning (such as, the knee rule) or validation.…”

Section: Introductionmentioning

confidence: 99%

Assessing time coalescence techniques for the analysis of supercomputer logs

Martino

Cinque

Cotroneo

2012

IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2012)

View full text Add to dashboard Cite

This paper presents a novel approach to assess time coalescence techniques. These techniques are widely used to reconstruct the failure process of a system and to estimate dependability measurements from its event logs. The approach is based on the use of automatically generated logs, accompanied by the exact knowledge of the ground truth on the failure process. The assessment is conducted by comparing the presumed failure process, reconstructed via coalescence, with the ground truth. We focus on supercomputer logs, due to increasing importance of automatic event log analysis for these systems. Experimental results show how the approach allows to compare different time coalescence techniques and to identify their weaknesses with respect to given system settings. In addition, results revealed an interesting correlation between errors caused by the coalescence and errors in the estimation of dependability measurements.

show abstract

Crash Data Collection: A Windows Case Study

Cited by 34 publications

References 10 publications

Charting the API minefield using software telemetry data

Charting the API minefield using software telemetry data

Predicting method crashes with bytecode operations

Assessing time coalescence techniques for the analysis of supercomputer logs

Contact Info

Product

Resources

About