To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Bugs

Apr 15 2013

A bug is a slang term for a software error. Any undocumented program behavior can be called an error. But the word "bug" is specifically used to denote a particular type of errors - those which are detected only during program execution instead of the earlier stages of software design, coding, or debugging.

Etymology of this term dates back to September 9, 1947, when the 'Mark II' computer was undergoing some tests. Operators traced an error in the 'Mark II' to a moth trapped between pins of an electromechanical relay. The insect was removed and taped to the log book with a notation "First actual case of bug being found" written next to it.

Bugs arise from programmer mistakes made by people in a program's source code or its design, or compiler errors. An application's behavior may also be affected by bugs in third-party libraries employed by the application. Improper use of libraries may also lead to bugs. Compiler errors usually occur because of incorrect optimization of programming language constructs. However, these are very rare. Usually those bugs programmers are accustomed to blame the compiler for, appear to be their own fault if you look closer (see the post "The compiler is to blame for everything").

Special tools called debuggers are used in most cases to detect code fragments containing bugs. They allow you to track variable values, processor register values, and other parameters affecting program execution, as well as some other crucial parameters. There also exist other methods of bug detection: static analysis and dynamic analysis.

Many software errors may not reveal themselves in any way but be exploited by a malicious user to hack a computer system. The most common bugs that can be used for this purpose are a buffer overflow and an integer overflow. When these bugs occur in system software, they can be used to obtain administrator rights in order to execute user applications. Additional check of input data is required to avoid such errors.

It is a common myth that a device employing a software system (a digital device) is much safer than a device fulfilling the same functions but not using any software (an analog device). The examples below are meant to disprove this myth - it's no way easier to develop a reliable digital system than an analog one.

Software bugs are sometimes directly responsible for human casualties or million-dollar damages. There exist many examples of that. For instance, the "Ariane 5" rocket was destroyed almost immediately after launch, which happened due to a set of reasons. The rocket reused the inertial reference platform from the "Ariane 4", while that platform was not designed for the new rocket's greater horizontal acceleration. The platform used a software unit that converted floating-point data into 16-bit signed integer. It is where the greater horizontal acceleration caused an overflow to occur. Range checks for this particular variable were omitted due to efficiency considerations that required an 80% maximum processor load. This factor therefore also contributed to the failure. The most ironic thing is that the unit that caused the failure wasn't necessary anymore when the crash happened. Its output data had been required during the first 7 seconds of the flight and they had been correct at the time. The rocket crashed at the 37-th second.

Between 1985 and 1987, 6 patients were given massive overdoses of radiation due to bugs in the Therac-25 radiation therapy machine. Previous models also had bugs, but they also had hardware interlock to prevent overdosing, so no one had been given lethal overdoses. One of the main bugs responsible for the accidents was a race condition occurring when inputting data for a therapy session.

As we see, the both accidents occurred due to reuse of software containing bugs from previous models. Lack of testing of the units' software was also a critical factor. This is just inadmissible in safety-critical systems! The consequences of these accidents could have been avoided if all the bugs responsible for those had been revealed at the early stages of software development and testing.

However, the cherished dream of having software absolutely free of bugs is far from being fulfilled. One of the methods to somehow deal with this issue in safety-critical systems is to classify bugs into critical and non-critical ones. Protection against critical bugs can be provided by using hardware protection mechanisms, backup units, and other means.

We should also keep in mind that only complex software testing and quality enhancement can prevent most bugs. You cannot take just a couple of methods that could provide the highest quality of software.

References

Popular related articles
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept