Tricorder: Building a Program Analysis Ecosystem

Sadowski, Caitlin; Gogh, Jeffrey van; Jaspan, Ciera; Söderberg, Emma; Winter, Collin

doi:10.1109/icse.2015.76

Cited by 138 publications

(156 citation statements)

References 24 publications

Supporting

Mentioning

151

Contrasting

Order By: Relevance

“…While both TRAVISPOKER and TRAVISHARVESTER utilize TRAVIS CI's Ruby client for querying the API, 6 we cannot use its job log retrieval function (Job:log) due to a memory leak 7 and because it does not retrieve all build logs. We circumvented these problems by also querying an undocumented Amazon Cloud server we discovered that archives build logs.…”

Section: Toolsmentioning

confidence: 99%

“…Under 5 , we can see a lightly parsed and colorized dump of the log file created when executing the build. By clicking 6 , developers can trigger a re-execution of a build. Build Setup.…”

Section: Travis CImentioning

confidence: 99%

“…Testing is central to CI. Two studies on the impact of compilation problems and ASATs at Google found that missing dependencies are the most important reason for builds to break [6,9]. However, these studies have not considered the testing phase of CI.…”

Section: Introductionmentioning

confidence: 99%

“…If any of these three phases fails, the whole CI build is typically aborted and regarded as broken [8]. Researchers have explored the compile and ASAT phase of CI [6,9]; yet, we still lack a quantitative empirical investigation of the testing phase to gain a holistic understanding of the CI process. This is surprising, as testing stands central in CI [2] and a better understanding is the first step to further improve both the CI process and the build tools involved.…”

Section: Introductionmentioning

confidence: 99%

“…A full CI build comprises 1) a traditional build and compile phase, 2) a phase in which automated static analysis tools (ASATs) such as FINDBUGS and JSHINT are run [6,7], and 3) a testing phase, in which unit, integration, and system tests are run. If any of these three phases fails, the whole CI build is typically aborted and regarded as broken [8].…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

View full text Add to dashboard Cite

Continuous Integration (CI) has become a best practice of modern software development.At present, we have a shortfall of insight into the testing practices that are common in CIbased software development. In particular, we seek quantifiable evidence on how central testing really is in CI, how strongly the project language influences testing, whether different integration environments are valuable and if testing on the CI can serve as a surrogate to local testing in the IDE. In an analysis of 2,640,825 Java and Ruby builds on Travis CI, we find that testing is the single most important reason why builds fail.Moreover, the programming language has a strong influence on both the number of executed tests, their test run time and proneness to fail. The use of multiple integration environments leads to 10% more failures being caught at build time. However, testing in the CI does not seem to be a good surrogate for running tests in the IDE.

show abstract

Section: Toolsmentioning

confidence: 99%

“…Under 5 , we can see a lightly parsed and colorized dump of the log file created when executing the build. By clicking 6 , developers can trigger a re-execution of a build. Build Setup.…”

Section: Travis CImentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Beller

Gousios

Zaidman

2016

Preprint

View full text Add to dashboard Cite

show abstract

Identifying unusual commits on GitHub

Goyal

Ferreira

Kästner

et al. 2017

J Software Evolu Process

View full text Add to dashboard Cite

Transparent environments and social-coding platforms as GitHub help developers to stay abreast of changes during the development and maintenance phase of a project. Especially, notification feeds can help developers to learn about relevant changes in other projects. Unfortunately, transparent environments can quickly overwhelm developers with too many notifications, such that they lose the important ones in a sea of noise. Complementing existing prioritization and filtering strategies based on binary compatibility and code ownership, we develop an anomaly detection mechanism to identify unusual commits in a repository, which stand out with respect to other changes in the same repository or by the same developer. Among others, we detect exceptionally large commits, commits at unusual times, and commits touching rarely changed file types given the characteristics of a particular repository or developer. We automatically flag unusual commits on GitHub through a browser plug-in. In an interactive survey with 173 active GitHub users, rating commits in a project of their interest, we found that, although our unusual score is only a weak predictor of whether developers want to be notified about a commit, information about unusual characteristics of a commit changes how developers regard commits. Our anomaly detection mechanism is a building block for scaling transparent environments. KEYWORDSanomaly detection, information overload, notification feeds, software ecosystems, transparent environments INTRODUCTIONCollaborative development in open source, software ecosystems, and also industrial software systems relies increasingly on decentralized decision making. 1-4 Interdependent components evolve independently and often with little explicit collaboration. Backward-incompatible changes that break modularity and produce rippling effects on downstream components are often necessary to avoid opportunity costs (not fixing mistakes, stifling change in the face of evolving requirements) and common in practice. [5][6][7][8][9][10][11][12][13][14][15] In addition, components may change to add new functionality that developers might want to adopt. Identifying relevant changes and reacting to them if needed can create a significant burden on developers during maintenance. 10,[15][16][17][18][19][20] Seeds of a solution can be found in today's transparent environments or social-coding platforms such as GitHub, LaunchPad, and Bitbucket. These environments provide mechanisms for notification and exploration, that help developers to stay abreast of activities across collections of projects without central planning. 21,22 For example, on GitHub, developers can watch projects and receive a notification feed of activities in watched projects, such as push events or bug reports. These tools work well at small scales but break down for large projects where imprecise and insufficiently rich notification mechanisms lead to information overload from notification cluttering. By inspecting publicly available events on GitHub, we found t...

show abstract

Function call interception techniques

Kang¹

2017

Softw Pract Exp

View full text Add to dashboard Cite

Function call interception (FCI), or method call interception (MCI) in the object-oriented programming domain, is a technique of intercepting function calls at program runtime. Without directly modifying the original code, FCI enables to undertake certain operations before and/or after the called function or even to replace the intercepted call. Thanks to this capability, FCI has been typically used to profile programs, where functions of interest are dynamically intercepted by instrumentation code so that the execution control is transferred to an external module that performs execution time measurement or logging operations. In addition, FCI allows for manipulating the runtime behavior of program components at the fine-grained function level, which can be useful in changing an application's original behavior at runtime to meet certain execution requirements such as maintaining performance characteristics for different input problem sets. Due to this capability, however, some FCI techniques can be used as a basis of many security exploits for vulnerable systems. In this paper, we survey a variety of FCI techniques and tools along with their applications to diverse areas in the computing and software domains. We describe static and dynamic FCI techniques at large and discuss the strengths and weaknesses of different implementations in this category. In addition, we also discuss aspect-oriented programming implementation techniques for intercepting method calls.

show abstract

Tricorder: Building a Program Analysis Ecosystem

Cited by 138 publications

References 24 publications

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Oops, my tests broke the build: An analysis of Travis CI builds with GitHub

Identifying unusual commits on GitHub

Function call interception techniques

Contact Info

Product

Resources

About