Bugs In Code Research Articles

AI-Powered Real-time Accessibility Enhancement: A Solution for Web Content Accessibility Issues

The web accessibility landscape is a significant challenge, with 96.3% of home pages displaying issues with Web Content Accessibility Guidelines (WCAG). This paper addresses the primary accessibility issues, such as missing Accessible Rich Internet Applications (ARIA) landmarks, ill-formed headings, low contrast text, and inadequate form labeling. The dynamic nature of modern web and cloud applications presents challenges, such as developers' limited awareness of accessibility implications, potential code bugs, and API failures. To address these issues, an AI-enabled system is proposed to dynamically enhance web accessibility. The system uses machine learning algorithms to identify and rectify accessibility issues in real-time, integrating with existing development workflows. Empirical evaluation and case studies demonstrate the efficacy of this solution in improving web accessibility across diverse scenarios.

Optimization of Smart Sensor for Balance Between Code Bug Ratio and Energy Consumption

This article studies the refactoring problem of smart sensors whose energy supply is limited. Refactoring helps smart sensors to wipe out code bugs (CBs) while consuming its limited energy. A smart sensor may need more than one refactoring. The more energy consumed by a refactoring, the more CBs may be removed by this refactoring, while the less energy will be left for the other refactorings (subsequently, less CBs may be reduced by the other refactorings). Therefore, how to make the optimal tradeoff for smart sensors between CB ratio (CBR) and energy consumption arises as an interesting problem. To address this problem, this article first establishes a constrained optimization-theoretical framework that can allocate the limited energy for refactorings, second explores out the optimal amount of energy supply for each refactoring that can minimize the CBR, third discovers the theoretical value, lower bound, upper bound, infimum, supremum, and convergence properties of the minimum CBR, and finally proposes an effective algorithm to minimize the CBR within the given energy level. To our best knowledge, this is the initial work toward this issue. Simulation and field experiments both document the performance.

Results of the Assessment of Possibilities and Prospects of Using Blockchain Technology in the Production Activities of Enterprises

The basics of Blockchain technology and its application in various fields of activity are considered. The object of the research is Blockchain technology and the possibilities of its application in industries. This involves a detailed study of its fundamental components – decentralized network, mathematical cryptography, distributed consensus, transaction ledger and smart contracts, as well as their application, in particular, for automating and securing transactions and processes using smart contracts. The main problem to be solved is the integration of secure, transparent and efficient mechanisms for recording and processing transactions, as well as automating processes at different stages of production. The use of Blockchain, or rather smart contracts, has significantly improved production processes by automating routine operations and ensuring the security of transactions. Smart contracts developed using the Ethereum platform and the Solidity language are able to optimize production processes, but they are not devoid of risks, such as code bugs and cybersecurity issues. It is emphasized that the integration of Blockchain into production processes requires a basic understanding of the technology, a clear implementation strategy, and initial investment in infrastructure and integration. Despite the initial difficulties, the benefits of using Blockchain in terms of transparency, efficiency, and reliability can be significant, as evidenced by several specific examples. The authors explore the potential of smart contracts at different stages of the production cycle, highlighting the benefits in automating processes and ensuring security. The results show that smart contracts can significantly improve production processes by automating routine operations and ensuring transparency and security of transactions.

CTOS: Compiler Testing for Optimization Sequences of LLVM

Optimization sequences are often employed in compilers to improve the performance of programs, but may trigger critical compiler bugs, e.g., compiler crashes. Although many methods have been developed to automatically test compilers, no systematic work has been conducted to detect compiler bugs when applying arbitrary optimization sequences. To resolve this problem, two main challenges need to be addressed, namely the acquisition of representative optimization sequences and the selection of representative testing programs, due to the enormous number of optimization sequences and testing programs. In this study, we propose CTOS, a novel compiler testing method based on differential testing, for detecting compiler bugs caused by optimization sequences of LLVM. CTOS first leverages the technique Doc2Vec to transform optimization sequences into vectors to capture the information of optimizations and their orders simultaneously. Second, a method based on the region graph and call relationships is developed in CTOS to construct the vector representations of the testing program, such that the semantics and the structure information of programs can be captured simultaneously. Then, with the vector representations of optimization sequences and testing programs, a “centroid” based selection scheme is proposed to address the above two challenges. Finally, CTOS takes in the representative optimization sequences and testing programs as inputs, and tests each testing program with all the representative optimization sequences. If there is an output that is different from the majority of others of a given testing program, then the corresponding optimization sequence is deemed to trigger a compiler bug. Our evaluation demonstrates that CTOS significantly outperforms the baselines by up to <inline-formula><tex-math notation="LaTeX">$24.76\% \sim 50.57\%$</tex-math></inline-formula> in terms of the bug-finding capability on average. Within seven month evaluations on LLVM, we have reported 104 valid bugs within 5 types, of which 21 have been confirmed or fixed. Most of those bugs are crash bugs (57) and wrong code bugs (24). 47 unique optimizations are identified to be faulty and 15 of them are loop related optimizations.

ATOM: Architectural Support and Optimization Mechanism for Smart Contract Fast Update and Execution in Blockchain-Based IoT

Blockchain-based Internet of Things (BC-IoT) brings the advantages of blockchain into traditional IoT systems. In BC-IoT, the smart contract has been widely used for automatic, trusted, and decentralized applications. Smart contracts require frequent adjust and fast update due to various reasons, such as inevitable code bugs, changes of applications, or security requirements. However, previous smart contract architecture and updating mechanism are low speed and cause high overhead, because they are based on recompilation and redeployment in BC-IoT. Meanwhile, smart contract execution is so time consuming due to contract instruction dispatching and operand loading in the stack-based Ethereum virtual machine (EVM). To address these issues, we propose a new smart contract architecture and optimization mechanism for BC-IoTs, ATOM, which provides architectural supports to update contract economically and fast executing in instructionwise for the first time, to the best of our knowledge. We design a compact Application-oriented Instruction (AoI) set to describe application operations. We can construct the bytecode of smart contract from application by directly assembling templates prebuilt upon the AoIs rather than by compilation. We also present an optimized mechanism for AoI execution to enable access addressable storage place rather than the indirect access through stack. We perform ATOM on a BC-IoT testbed based on private Ethereum and Hyperledger Burrow. The experimental results highlight that ATOM is more efficient than state-of-the-art approaches. ATOM can reduce update latency by 62.7%, ledger size by 70%, and gas usage by 90% on average, respectively. Compared with the traditional smart contract architecture, ATOM can improve EVM Memory access efficiency significantly by up to <inline-formula xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink"> <tex-math notation="LaTeX">$10\times $ </tex-math></inline-formula> and achieve improvement of execution efficiency with up to <inline-formula xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink"> <tex-math notation="LaTeX">$1.6\times $ </tex-math></inline-formula> .

Rotten green tests in Java, Pharo and Python

Rotten Green Tests are tests that pass, but not because the assertions they contain are true: a rotten test passes because some or all of its assertions are not actually executed. The presence of a rotten green test is a test smell, and a bad one, because the existence of a test gives us false confidence that the code under test is valid, when in fact that code may not have been tested at all. This article reports on an empirical evaluation of the tests in a corpus of projects found in the wild. We selected approximately one hundred mature projects written in each of Java, Pharo, and Python. We looked for rotten green tests in each project, taking into account test helper methods, inherited helpers, and trait composition. Previous work has shown the presence of rotten green tests in Pharo projects; the results reported here show that they are also present in Java and Python projects, and that they fall into similar categories. Furthermore, we found code bugs that were hidden by rotten tests in Pharo and Python. We also discuss two test smells —missed fail and missed skip —that arise from the misuse of testing frameworks, and which we observed in tests written in all three languages.

Five best practices for fMRI research: Towards a biologically grounded understanding of mental phenomena

The replication crisis in science has not spared functional magnetic resonance imaging (fMRI) research. A range of issues including insufficient control of false positives, code bugs, concern regarding generalizability and replicability of findings, inadequate characterization of physiological confounds, over-mining of repository datasets, and the small sample sizes/low power of many early studies have led to hearty debate in both the field and the press about the usefulness and viability of fMRI. Others still see enormous potential for fMRI in diagnosing conditions that do not otherwise lend themselves to non-invasive biological measurement, from chronic pain to neurological and psychiatric illness. How do we reconcile the limitations of fMRI with the hype over its potential? Despite many papers hailed by the press as the nail in the coffin for fMRI, from the dead salmon incident of 2009 to cluster failure more recently, funders, researchers, and the general public do not seem to have reduced their appetite for pictures of brain maps, or gadgets with the word “neuro” in the name. Multiple blogs exist for the sole purpose of criticizing such enterprise. The replicability crisis should certainly give ‘neuroimagers’ pause, and reason to soul-search. It is more important than ever to clarify when fMRI is and when it is not useful. The method remains the best noninvasive imaging tool for many research questions, however imperfect and imprecise it may be. However, to address past limitations, I argue neuroimaging researchers planning future studies need to consider the following five factors: power/effect size, design optimization, replicability, physiological confounds, and data sharing.

Java 프로그램 단위 테스트 코드에서 발생하는 결함의 분류와 패턴 정의

단위 테스트 케이스를 이용한 자동 회귀 테스팅 방법론이 널리 사용됨에 따라, 단위 테스트 케이스 작성 중 발생하는 ‘테스트 코드 결함’이 소프트웨어 제품의 품질과 프로젝트의 생산성을 저하하는 새로운 소프트웨어 품질 문제로 대두되고 있다. 이러한 단위 테스트 코드 결함의 체계적인 이해와 탐지를 위하여, 본 논문에서는 Java 프로그램 단위 테스트 케이스 결함을 분류하는 결함 분류 체계와 실제 결함사례에 기반한 단위 테스트 케이스 결함 패턴을 소개한다. 테스트 케이스 결함에 대한 단편적인 분류 기준을 제시하는 기존 연구와 달리, 본 연구에서는 단위 테스트 코드의 다양한 구조적, 기능적, 의미적 구성요소의 범주를 제시한 후 이에 기반한 총체적인 분류 체계를 제안하며, 이를 이용해 실제 결함 사례와 정적 결함 검출기의 검출대상을 분류한 결과 소개한다. 이에 더하여, 본 논문에서는 실제 테스트 결함 사례로부터, 테스트 코드 결함의 주요 조건을 구체적이고 명확하게 표현한 새로운 8종의 테스트 결함 패턴을 소개한다.

Analysis of User Activities and Generation of Log File using Java Applications

Cyber security and fraud identification are gaining priority with the rise in cyber crime. Any computer on a network is vulnerable to unauthorized access or cyber attacks (bruteforce, DoS, etc.). To deal with these threats of frauds, cyber attacks or unauthorized access, it is important to track the activities of user on any application or website. Logging of user activities and events performed along with the time of access can help the developer to find out the bugs in code as well as the clandestine moves of any user. This paper deals with the significance of the important aspects of logging the details of user activity for secure and easy access of an application. For this, it uses logging framework tools like log4j provided by Apache, to track all the user activities which can be later used for maintenance as well as security purposes.

Fast and precise type checking for JavaScript

In this paper we present the design and implementation of Flow, a fast and precise type checker for JavaScript that is used by thousands of developers on millions of lines of code at Facebook every day. Flow uses sophisticated type inference to understand common JavaScript idioms precisely. This helps it find non-trivial bugs in code and provide code intelligence to editors without requiring significant rewriting or annotations from the developer. We formalize an important fragment of Flow's analysis and prove its soundness. Furthermore, Flow uses aggressive parallelization and incrementalization to deliver near-instantaneous response times. This helps it avoid introducing any latency in the usual edit-refresh cycle of rapid JavaScript development. We describe the algorithms and systems infrastructure that we built to scale Flow's analysis.

Threshold design for cohesion and coupling metrics using K-means clustering Algorithm

As open source systems are becoming popular these days, there is more and more pressure on development teams to produce high-quality software. The quality of system (QoS) suffers even after undergoing testing; code smells still remain in the system. Various studies have been focusing on the relationship between metrics and code smells of class. Studies show that various metrics metric have been proposed to check the design quality of software during the development phase. A code smell is a suggestion or the description of an indication that something has gone wrong your code. Refactoring is done to clean the code and to decrease the chance of presenting the bugs in code. In this paper, describee is carried out to examine the relationship between cohesion and coupling metric and bad code smell for the open source code of ArgoUML four versions 0.24, 0.28, 0.30 and 0.34. Cohesion and coupling metrics design is done with the help of SourceMeter tool. PMD is used to collect all the bad code smell which are affecting the class. After that used technique k-means clustering, are used to find the threshold. In this work, it is proposed to use a clustering and metrics threshold based software bad code smell prediction approach and explore it on the dataset of ArgoUML versions. Clustering techniques have more importance in data mining especially when the data size is very large. Further, in this paper, the k-means algorithm has been applied for predicting code smells in program modules. Predicted models for one version are applied on other versions to check their accuracy. The results of the analysis are then used to conduct code smell classification based on the accuracy of one ArgoUML version and compared against the result of another version of ArgoUML.

Open science in mental health research

Open science in mental health research

A Survey on Effective Bug Prioritizing using Instance Selection and Feature Selection Techniques

Background/Objectives: This paper represents a review of how to fix bugs and how to accurately assign a brand new bug to a particular developer. Software firms pay over 45 % of value in coping with computer code bugs. A complicated process of fixing bugs is bug triage that aims to accurately assign a developer to a brand new bug. To diminish the time value in human work, text classification techniques are used to conduct automatic bug sorting. Methods: Findings: In this paper, we possess a mind set to address the problem of knowledge reduction for bug sorting, i.e., the means to prune back the ratio and improve the standard of bug knowledge. We associate instance selection with feature selection to at the same time cut back knowledge ratio on the bug dimension and also the word dimension. To make away the parliamentary procedure of applying instance selection and feature election, we extract attributes from historical bug knowledge sets and build a prophetic model for a brand new bug knowledge set. We induce a tendency to thorough empirical observation and to investigate the execution of data reduction of the whole 600,000 bug reports of 2 giant open supply comes, namely Eclipse and Mozilla. Data reduction techniques such as classification and prediction method can be used to cut down the large bug dataset (by removing noisy and irrelevant data), and predict the correct answer for the bugs by applying keywords and properties. A classification method such as Bayesian Classification is used to classify the incoming bug dataset. Properties of Instance Selection and Feature Selection techniques are merged along with the attributes and keywords to solve the problem of bug prioritizing. Applications/Improvements: These outcomes demonstrate that the data reduction will effectively cut back the knowledge ratio and improve the accuracy of bug sorting. Our work provides associate approach to investment techniques on processing to create decreased and high-quality bug expertise in computer code development and sustenance. Regression analysis techniques can also be applied to a decision table to calculate the effort that is needed to resolve an incoming bug.

Message filters for hardening the Linux kernel

AbstractVarious mechanisms for hardening the Linux kernel (for example, enforcing system call policies, device driver failure recovery, protection against exploitation of bugs in code) are proposed in the literature. The main problem with these mechanisms is that, they require changes in the kernel code leading to the possibility of introducing new bugs and hence increasing the testing time. We propose a message filter model as an extension to object‐oriented wrappers for the Linux kernel, to dynamically provide various filtering capabilities to the kernel. This model works as a comprehensive framework for specifying system call policies, handling device driver faults, protecting the kernel against exploits of bugs in code etc, without modifying the existing kernel code. This considerably reduces the possibility of creating new bugs in the kernel code. We have integrated policies for system call interception and device driver failure handling, into the Linux kernel (2.6.9), using message filter model. Our experiments show that the overhead due to our filter objects is very low, making it a useful mechanism for providing filtering capabilities to the Linux kernel. Copyright © 2010 John Wiley &amp; Sons, Ltd.

Advanced firmware verification using a code simulator for the IBM System z9

Our methods for simulating host firmware of the IBM System z9™ facilitated rapid development from first power-on of the system to achieving a platform with a functional operating system. Hundreds of code bugs were eliminated before the code was run on System z9 hardware for the first time. This paper describes the methods used in host firmware simulation for early and efficient firmware tests. The central element for firmware simulation is the Central Electronic Complex Simulator (CECSIM), which offers new facilities to manage the hardware of the simulated system. This management includes concurrent configuration changes of processors, memory, and I/O along with the ability to automatically test complex system functions. To verify correct implementation of the z/Architecture™, we introduced a new test-case framework called the Verification Interface for System Architecture, or VISA, which is used in simulations as well as on the actual system. All of these features are used separately and in combination. A comprehensive and flexible regression environment ensures periodic execution of the test scenarios, and code path coverage measurements show the degree to which the code was actually verified.

Identifying Failure Causes in Java Programs: An Application of Change Impact Analysis

During program maintenance, a programmer may make changes that enhance program functionality or fix bugs in code. Then, the programmer usually will run unit/regression tests to prevent invalidation of previously tested functionality. If a test fails unexpectedly, the programmer needs to explore the edit to find the failure-inducing changes for that test. Crisp uses results from Chianti, a tool that performs semantic change impact analysis [1], to allow the programmer to examine those parts of the edit that affect the failing test. Crisp then builds a compilable intermediate version of the program by adding a programmer-selected partial edit to the original code, augmenting the selection as necessary to ensure compilation. The programmer can reexecute the test on the intermediate version in order to locate the exact reasons for the failure by concentrating on the specific changes that were applied. In nine initial case studies on pairs of versions from two real Java programs, Daikon [2] and Eclipse jdt compiler [3], we were able to use Crisp to identify the failure-inducing changes for all but 1 of 68 failing tests. On average, 33 changes were found to affect each failing test (of the 67), but only 1-4 of these changes were found to be actually failure-inducing.

Software archaeology

This isn't programming, this is archaeology! the programmer complained, wading through the ancient rubble of some particularly crafty pieces of code. It's a pretty good analogy, actually. In real archaeology, you're investigating some situation, trying to understand what you're looking at and how it all fits together. To do this, you must be careful to preserve the artifacts you find and respect and understand the cultural forces that produced them. But we don't have to wait a thousand years to try to comprehend unfathomable artifacts. Code becomes legacy code just about as soon as it's written, and suddenly we have exactly the same issues as the archaeologists. What are we looking at? How does it fit in with the rest of the world? And what were they thinking? It seems we're always in the position of reading someone else's code: either as part of a code review, or trying to customize a piece of open source software, or fixing a bug in code that we've inherited.

Putting static analysis to work for verification

A method for finding bugs in code is presented. For given small numbers j and k, the code of a procedure is translated into a rela-tional formula whose models represent all execution traces that involve at most j heap cells and k loop iterations. This formula is conjoined with the negation of the procedure's specification. The models of the resulting formula, obtained using a constraint solver, are counterexamples: executions of the code that violate the specification. The method can analyze millions of executions in seconds, and thus rapidly expose quite subtle flaws. It can accommodate calls to procedures for which specifications but no code is avail-able. A range of standard properties (such as absence of null pointer dereferences) can also be easily checked, using prede-fined specifications.

Abstract analysis with aspect

Aspect is a static analysis technique for detecting bugs in code based on three forms of abstraction: declarative specification, data abstraction and partiality (ignoring some behavioural details). Together, they bring efficiency (the checker runs almost as fast as a type checker), modularity (a procedure can be analysed independently of the procedures it calls) and incrementality (allowing the checking of incomplete programs). Aspect can detect errors that are not detectable by other static means, especially errors of omission, which are pervasive but usually hard to detect.