In computing, a service pack comprises a collection of updates, fixes, or enhancements to a software program delivered in the form of a single installable package. Companies often release a service pack when the number of individual patches to a given program reaches a certain (arbitrary) limit, or the software release has shown to be stabilized with a limited number of remaining issues based on users' feedback and bug reports . In large software applications such as office suites, operating systems, database software, or network management, it is not uncommon to have a service pack issued within the first year or two of a product's release. Installing a service pack is easier and less error-prone than installing many individual patches, even more so when updating multiple computers over a network, where service packs are common.
28-413: Service packs are usually numbered, and thus shortly referred to as SP1, SP2, SP3 etc. They may also bring, besides bug fixes, entirely new features, as is the case of SP2 of Windows XP (e.g. Windows Security Center ), or SP3 and SP4 of the heavily database dependent Trainz 2009: World Builder Edition . Service Packs for Microsoft Windows were cumulative through Windows XP . This means that
56-424: A program specification which states the behavior of a program, can prevent bugs. Some contend that formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy . One goal of software testing is to find bugs. Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable
84-444: A bug may be caused by a relatively minor, typographical error (typo) in the code. For example, this code executes function foo only if condition is true. But this code always executes foo : A convention that tends to prevent this particular issue is to require braces for a block even if it has just one line. Enforcement of conventions may be manual (i.e. via code review ) or via automated tools. Some contend that writing
112-453: A failure would not occur until later at runtime. Some languages exclude features that easily lead to bugs, at the expense of slower performance – the principle being that it is usually better to write simpler, slower correct code than complicated, buggy code. For example, the Java does not support pointer arithmetic which is generally fast, but is considered dangerous; relatively easy to cause
140-517: A later time, additional components are added to the software using the original media, there is a risk of accidentally mixing older and updated components. Depending on the operating system and deployment methods, it may then be necessary to manually reinstall the service pack after each such change to the software. This was, for example, necessary for Windows NT service packs; however, from Windows 2000 onwards, Microsoft redirected setup programs to use updated service pack files instead of files from
168-557: A major bug. Some languages include features that add runtime overhead in order to prevent some bugs. For example, many languages include runtime bounds checking and a way to handle out-of-bounds conditions instead of crashing. A compiled language allows for detecting some typos (such as a misspelled identifier) before runtime which is earlier in the software development process than for an interpreted language. Programming techniques such as programming style and defensive programming are intended to prevent typos. For example,
196-432: A measure of impact the bug has. This impact may be data loss, financial, loss of goodwill and wasted effort. Severity levels are not standardized, but differ by context such as industry and tracking tool. For example, a crash in a video game has a different impact than a crash in a bank server. Severity levels might be crash or hang , no workaround (user cannot accomplish a task), has workaround (user can still accomplish
224-488: Is easy to hide vulnerabilities in complex, little understood and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so." An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian . Debugging can be a significant part of the software development lifecycle . Maurice Wilkes , an early computing pioneer, described his realization in
252-435: Is typically to console , window , log file or a hardware output (i.e. LED ). Some contend that locating a bug is something of an art. It is not uncommon for a bug in one section of a program to cause failures in a different section, thus making it difficult to track, in an apparently unrelated part of the system. For example, an error in a graphics rendering routine causing a file I/O routine to fail. Sometimes,
280-468: The Therac-25 radiation machine deaths was a bug (specifically, a race condition ) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running
308-608: The US Department of Commerce 's National Institute of Standards and Technology concluded that "software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $ 59 billion annually, or about 0.6 percent of the gross domestic product". Since the 1950s, some computer systems have been designed to detect or auto-correct various software errors during operations. Mistake metamorphism (from Greek meta = "change", morph = "form") refers to
SECTION 10
#1732783213391336-688: The behavior a bug. However, Justin Brookman of the Center for Democracy and Technology directly challenged that portrayal, stating "I'm glad that they are fixing what they call bugs, but I take exception with their strong denial that they track users." Preventing bugs as early as possible in the software development process is a target of investment and innovation. Newer programming languages tend to be designed to prevent common bugs based on vulnerabilities of existing languages. Lessons learned from older languages such as BASIC and C are used to inform
364-400: The bug's severity and priority and external factors such as development schedules. Triage generally does not include investigation into cause. Triage may occur regularly. Triage generally consists of reviewing new bugs since the previous triage and maybe all open bugs. Attendees may include project manager, development manager, test manager, build manager, and technical experts. Severity is
392-411: The code and imagining or transcribing the execution process may often find errors without ever reproducing the bug as such. Typically, the first step in locating a bug is to reproduce it reliably. If unable to reproduce the issue, a programmer cannot find the cause of the bug and therefore cannot fix it. Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of
420-654: The code explicitly (perhaps as simple as a statement saying PRINT "I AM HERE" ), or provided as tools. It is often a surprise to find where most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten. Open source development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus's law says that popular open-source software has more chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however: computer security specialist Elias Levy wrote that "it
448-482: The code may eliminate the problem even though the code then no longer matches the documentation. In an embedded system , the software is often modified to work around a hardware bug since it's cheaper than modifying the hardware. Bugs are managed via activities like documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code. Tools are often used to track bugs and other issues with software. Typically, different tools are used by
476-472: The design of later languages such as C# and Rust . Languages may include features such as a static type system , restricted namespaces and modular programming . For example, for a typed, compiled language (like C ): is syntactically correct, but fails type checking since the right side, a string, cannot be assigned to a float variable. Compilation fails – forcing this defect to be fixed before development progress can resume. With an interpreted language,
504-541: The evolution of a defect in the final stage of software deployment. Transformation of a "mistake" committed by an analyst in the early stages of the software development lifecycle, which leads to a "defect" in the final stage of the cycle has been called 'mistake metamorphism'. Different stages of a mistake in the development cycle may be described as mistake, anomaly, fault, failure, error, exception, crash, glitch, bug, defect, incident, or side effect. Software bugs have been linked to disasters. Sometimes
532-462: The late 1940s that “a good part of the remainder of my life was going to be spent in finding errors in my own programs”. A program known as a debugger can help a programmer find faulty code by examining the inner workings of a program such as executing code line-by-line and viewing variable values. As an alternative to using a debugger, code may be instrumented with logic to output debug information to trace program execution and view values. Output
560-441: The longer a product is tested and developed. Agile software development may involve frequent software releases with relatively small changes. Defects are revealed by user feedback. With test-driven development (TDD), unit tests are written while writing the production code, and the production code is not considered complete until all tests complete successfully. Tools for static code analysis help developers by inspecting
588-424: The most difficult part of debugging is finding the cause of the bug. Once found, correcting the problem is sometimes easy if not trivial. Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmers. Often, such a logic error requires a section of the program to be overhauled or rewritten. Some contend that as a part of code review , stepping through
SECTION 20
#1732783213391616-419: The original installation media in order to prevent manual reinstall. Software bug A software bug is a design defect ( bug ) in computer software . A computer program with many or serious bugs may be described as buggy . The effects of a software bug range from minor (such as a misspelled word in the user interface ) to severe (such as frequent crashing ). In 2002, a study commissioned by
644-613: The problems that are fixed in a service pack are also fixed in later service packs. For example, Windows XP SP3 contains all the fixes that are included in Windows XP Service Pack 2 (SP2). Windows Vista SP2 was not cumulative, however, but incremental, requiring that SP1 be installed first. Office XP , Office 2003 , Office 2007 , Office 2010 and Office 2013 service packs have been cumulative. Application service packs replace existing files with updated versions that typically fix bugs or close security holes . If, at
672-526: The program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable (see halting problem ), these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes often when writing software. Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in
700-537: The program with a debugger; these are called heisenbugs (humorously named after the Heisenberg uncertainty principle ). Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation . Often, bugs come about during coding, but faulty design documentation may cause a bug. In some cases, changes to
728-468: The software development team to track their workload than by customer service to track user feedback . A tracked item is often called bug , defect , ticket , issue , feature , or for agile software development , story or epic . Items are often categorized by aspects such as severity, priority and version number . In a process sometimes called triage , choices are made for each bug about whether and when to fix it based on information such as
756-522: The task), visual defect (a misspelling for example), or documentation error . Another example set of severities: critical , high , low , blocker , trivial . The severity of a bug may be a separate category to its priority for fixing, or the two may be quantified and managed separately. Software development process Too Many Requests If you report this error to the Wikimedia System Administrators, please include
784-548: The use of bug to describe the behavior of software is contentious due to perception. Some suggest that the term should be abandoned; replaced with defect or error . Some contend that bug implies that the defect arose on its own and push to use defect instead since it more clearly connotates caused by a human. Some contend that bug may be used to coverup an intentional design decision. In 2011, after receiving scrutiny from US Senator Al Franken for recording and storing users' locations in unencrypted files, Apple called
#390609