Application of social networking algorithms in program analysis: understanding execution frequencies

2011 Summer.Includes bibliographical references.There may be some parts of a program that are more commonly used at runtime, whereas there may be other parts that are less commonly used or not used at all. In this exploratory study, we propose an approach to predict how frequently or rarely different parts of a program will get used at runtime without actually running the program. Knowledge of the most frequently executed parts can help identify the most critical and the most testable parts of a program. The portions predicted to be the less commonly executed tend to be hard to test parts of a program. Knowing the hard to test parts of a program can aid the early development of test cases. In our approach we statically analyse code or static models of code (like UML class diagrams), using quantified social networking measures and web structure mining measures. These measures assign ranks to different portions of code for use in predictions of the relative frequency that a section of code will be used. We validated these rank ordering of predictions by running the program with a common set of use cases and identifying the actual rank ordering. We compared the predictions with other measures that use direct coupling or lines of code. We found that our predictions fared better as they were statistically more correlated to the actual rank ordering than the other measures. We present a prototype tool written as an eclipse plugin, that implements and validates our approach. Given the source code of a Java program, our tool computes the values of the metrics required by our approach to present ranks of all classes in order of how frequently they are expected to get used. Our tool can also instrument the source code to log all the necessary information at runtime that is required to validate our predictions

Identification of the Impacts of Code Changes on the Security of Software

Companies develop their software in versions and iterations. Ensuring the security of each additional version using code review is costly and time consuming. This paper investigates automated tracing of the impacts of code changes on the security of a given software. To this end, we use call graphs to model the software code, and security assurance cases to model the security requirements of the software. Then we relate assurance case elements to code through the entry point methods of the software, creating a map of monitored security functions. This mapping allows to evaluate the security requirements that are affected by code changes. The approach is implemented in a set of tools and evaluated using three open-source ERP/E-commerce software applications. The limited evaluation showed that the approach is effective in identifying the impacts of code changes on the security of the software. The approach promises to considerably reduce the security assessment time of the subsequent releases and iterations of software, keeping the initial security state throughout the software lifetime

The Rascal Language Workbench

Rascal is a programming language for source code analysis and transformation. This means that typically the input of a Rascal program is a program in some programming language, and the output is often yet another program. So Rascal is a meta programming language. Source code is thus primary object of manipulation in Rascal. Many of the use cases that Rascal is designed to address, follow the Extract-Analyze- SYnthesize, or EASY paradigm (shown in Figure 1.1). Meta programs often start by extracting information (facts) from the input program. This is the extraction phase. An example could be the call-graph of a program. Then, this extracted information is often subject to analysis: derived facts are computed, the information is enriched. For the call graph, a simple analysis is determining the root or leaf routines in the a source program by analysing the extracted call-graph. Another analysis could be concerned by identifying routines that are never called (dead code). Finally, the meta program will synthesize some kind of result. This can be transformed source code (e.g., removal of dead code from the input program), a report (e.g., statistics on the number of root and leaf routines), or a visualization (e.g., a graphical depiction of the call-graph). Of course, these phases are not strictly sequential: there may be feedback loops. Some analysis leads to new extraction, synthesis of a result may lead to new analyses and so on. Rascal has elaborated features to support each of the phases of the EASY paradigm fully integrated in the language. Naturally, the implementation of domain specific languages (DSLs), or more generally, modeldriven engineering (MDE) fits the EASY paradigm very well. When implementing a DSL compiler or interpreter the input is, of course, DSL source code. Extraction could, for instance, include the derivation of an AST from the concrete syntax tree. Another extracted model could be a graph-like structure representing the input in a more abstract way, or a performance model. Such abstractions are input to analyses such as constraint checking or type checking, verification, quality-of-service analysis etc. Finally, synthesis covers tasks such as graphical visualization, code generation, and optimization. To conclude, in the context of Rascal, we see DSL implementation as an instance of source code analysis and transformation

Trace-based automated logical debugging for high-level synthesis generated circuits

In this paper we present an approach for debugging hardware designs generated by High-Level Synthesis (HLS), relieving users from the burden of identifying the signals to trace and from the error-prone task of manually checking the traces. The necessary steps are performed after HLS, independently of it and without affecting the synthesized design. For this reason our methodology should be easily adaptable to any HLS tools. The proposed approach makes full use of HLS compile time informations. The executions of the simulated design and the original C program can be compared, checking if there are discrepancies between values of C variables and signals in the design. The detection is completely automated, that is, it does not need any input but the program itself and the user does not have to know anything about the overall compilation process. The design can be validated on a given set of test cases and the discrepancies are detected by the tool. Relationships between the original high-level source code and the generated HDL are kept by the compiler and shown to the user. The granularity of such discrepancy analysis is per-operation and it includes the temporary variables inserted by the compiler. As a consequence the design can be debugged as is, with no restrictions on optimizations available during HLS. We show how this methodology can be used to identify different kind of bugs: 1) introduced by the HLS tool used for the synthesis; 2) introduced using buggy libraries of hardware components for HLS; 3) undefined behavior bugs in the original high-level source code

QParallel: Explicit Parallelism for Programming Quantum Computers

We present a language extension for parallel quantum programming to (1) remove ambiguities concerning parallelism in current quantum programming languages and (2) facilitate space-time tradeoff investigations in quantum computing. While the focus of similar libraries in the domain of classical computing (OpenMP, OpenACC, etc.) is to divide a computation into multiple threads, the main goal of QParallel is to keep the compiler and the runtime system from introducing parallelism-inhibiting dependencies, e.g., through reuse of qubits in automatic qubit management. We describe the syntax and semantics of the proposed language extension, implement a prototype based on Q#, and present several examples and use cases to illustrate its performance benefits. Moreover, we introduce a tool that guides programmers in the placement of parallel regions by identifying the subroutines that profit most from parallelization, which is especially useful if the programmer's knowledge of the source code is limited. Support for QParallel can be added to any multithreading library and language extension, including OpenMP and OpenACC.Comment: 9 pages, 8 figure

Automatic binary patching for flaws repairing using static rewriting and reverse dataflow analysis

Tese de Mestrado, Segurança Informática, 2022, Universidade de Lisboa, Faculdade de CiênciasThe C programming language is widely used in embedded systems, kernel and hardware programming, making it one of the most commonly used programming languages. However, C lacks of boundary verification of variables, making it one of the most vulnerable languages. Because of this and associated with its high usability, it is also the language with most reported vulnerabilities in the past ten years, being the memory corruption the most common type of vulnerabilities, specifically buffer overflows. These vulnerabilities when exploited can produce critical consequences, being thus extremely important not only to correctly identify these vulnerabilities but also to properly fix them. This work aims to study buffer overflow vulnerabilities in C binary programs by identifying possible malicious inputs that can trigger such vulnerabilities and finding their root cause in order to mitigate the vulnerabilities by rewriting the binary assembly code and thus generating a new binary without the original flaw. The main focus of this thesis is the use of binary patching to automatically fix stack overflow vulnerabilities and validate its effectiveness while ensuring that these do not add new vulnerabilities. Working with the binary code of applications and without accessing their source code is a challenge because any required change to its binary code (i.e, assembly) needs to take into consideration that new instructions must be allocated, and this typically means that existing instructions will need to be moved to create room for new ones and recover the control flow information, otherwise the application would be compromised. The approach we propose to address this problem was successfully implemented in a tool and evaluated with a set of test cases and real applications. The evaluation results showed that the tool was effective in finding vulnerabilities, as well as in patching them

Tracing Naming Semantics in Unit Tests of Popular Github Android Projects

The tests are so closely linked to the source code that we consider them up-to-date documentation. Developers are aware of recommended naming conventions and other best practices that should be used to write tests. In this paper we focus on how the developers test in practice and what conventions they use. For the analysis 5 very popular Android projects from Github were selected. The results show that 49 % of tests contain full and 76 % of tests contain a partial unit under test (UUT) method name in their name. Further, there was observed that UUT was only rarely tested by multiple test classes and thus in cases when the tester wanted to distinguish the way he or she worked with the tested object. The analysis of this paper shows that the word "test" in the test title is not a reliable metric for identifying the test. Apart from assertions, the developers use statements like verify, try-catch and throw exception to verify the correctness of UUT functionality. At the same time it was found out that the test titles contained keywords which could lead to the identification of UUT, use case of test or data used for test. It was also found out that the words in the test title were very often found in its body and in a smaller amount in UUT body which indicated the use of similar vocabulary in tests and UUT

bflinks: Reliable Bugfix links via bidirectional references and tuned heuristics

Background: Data from software data repositories such as source code version archives and defect databases contains valuable information that can be used for insights (leading to subsequent improvements), in particular defect insertion circumstance analysis and defect prediction. The first step in such analyses is identifying defect-correcting changes in the version archive (bugfix commits) and linking them to corresponding entries in the defect database, thus establishing bugfix links, in order to enrich the content of the defect-correcting change with additional meta-data. Typically, identifying the bugfix commits in a version archive is done via heuristic string matching on the commit message. Research questions: Which filters could be used to obtain a set of bugfix links? How does one set the cutoff parameters of each? What effect (results loss and precision) does each filter then have? Which overall precision, results loss, and recall is achieved? Method: We analyze a comprehensive modular set of seven independent filters, including new ones that make use of reverse links. We describe and evaluate visual heuristics (based on simple diagnostic plots) for setting six filters' cutoff parameter. We apply these to a commercial repository from the Web CMS domain and validate the results with unprecendented precision by making use of a product expert to manually verify over 2500 links. Results: The parameter selection heuristics pick a very good parameter value in five of the six cases and a reasonably good one in the sixth. As a result, the combined filtering, called bflinks, proposes a set of bugfix links that has 93\% precision with only 7\% results loss. Conclusion: The modular filtering approach can provide high-quality results and can be adapted to repositories with different properties