Yuanjun Chen

dblp:132/2514 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 2013
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1

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
Program analysis · 75% Debugging and program repair · 25%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Debugging and program repair
fault localization
0.212013
Dynamically validating static memory leak warnings · ISSTA 2013
Program analysis › error detection
memory leak detection
0.212013
Dynamically validating static memory leak warnings · ISSTA 2013
Program analysis
static analysis
0.212013
Dynamically validating static memory leak warnings · ISSTA 2013
Program analysis
warning validation
0.212013
Dynamically validating static memory leak warnings · ISSTA 2013

Methods — techniques the papers use, named apart from their topics

test case generation · 0.2object tracking · 0.2dynamic analysis · 0.2
YearPublicationVenuePosition
2013 Dynamically validating static memory leak warnings
abstract
File Edit Options Buffers Tools TeX Help Memory leaks have significant impact on software availability, performance, and security. Static analysis has been widely used to find memory leaks in C/C++ programs. Although a static analysis is able to find all potential leaks in a program, it often reports a great number of false warnings. Manually validating these warnings is a daunting task, which significantly limits the practicality of the analysis. In this paper, we develop a novel dynamic technique that automatically validates and categorizes such warnings to unleash the power of static memory leak detectors. Our technique analyzes each warning that contains information regarding the leaking allocation site and the leaking path, generates test cases to cover the leaking path, and tracks objects created by the leaking allocation site. Eventually, warnings are classified into four categories: MUST-LEAK, LIKELY-NOT-LEAK, BLOAT, and MAY-LEAK. Warnings in MUST-LEAK are guaranteed by our analysis to be true leaks. Warnings in LIKELY-NOT-LEAK are highly likely to be false warnings. Although we cannot provide any formal guarantee that they are not leaks, we have high confidence that this is the case. Warnings in BLOAT are also not likely to be leaks but they should be fixed to improve performance. Using our approach, the developer's manual validation effort needs to be focused only on warnings in the category MAY-LEAK, which is often much smaller than the original set.
Mengchen Li, Yuanjun Chen, Linzhang Wang, Guoqing Harry Xu
ISSTA2