Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for Software Defect Detection and Problem Area Identification

IP.com Disclosure Number: IPCOM000124031D
Original Publication Date: 2005-Apr-06
Included in the Prior Art Database: 2005-Apr-06
Document File: 3 page(s) / 57K

Publishing Venue

IBM

Abstract

This article describes a software method for detecting a certain type of software defect and then identifying which component of the software most likely contains the defect. The type of defect that this can identify is the occurrence of an invalid increment or decrement to a counter value.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 3

Method for Software Defect Detection and Problem Area Identification

Disclosed is an invention for a method of determining when a certain type of software defect has occurred. Upon detection, the software provides information identifying which component of the software most likely contains the defect. The specific type of defect that this method can identify is the occurrence of an invalid increment or decrement to a counter value.

     The Virtual File System (VFS) is an interface specification for the UNIX* file interface. The VFS interface provides abstract objects, vnodes, which represent real objects in a file system. Vnodes can represent directories, files, FIFOs, sockets, etc. Multi-user access to the same object must result in each user obtaining and "owning" a reference to the object. A very efficient technique to manage these references is by using a counter. This technique is used for many UNIX and UNIX-like implementations in existence today.

     One problem associated with using such a lightweight reference counter is that there is no accountability for the various functions that obtain these references. Each of those functions will simply increment and decrement the counter as needed to indicate obtaining a reference and releasing a reference. Defective software could cause this counter to be incremented or decremented too many times. When that happens, the integrity of the underlying file system object can be compromised, because the reference count may incorrectly represent the number of users of the object. Operating system code may then make incorrect decisions based on the counter's value. For example, if a file system vnode's counter is decremented to 0 prematurely, it may result in that vnode getting reused for a different file system object while other tasks still think it refers to the first object. Although the operating system can detect one of these scenarios (for example, decrementing the counter below 0), there is no postmortem way to determine where the counter started getting incorrectly updated.

     One solution to the problem would be to stop using a counter, and use a shared locking technique that then associated each user's process with their lock instance. However, the overhead of such a scheme can be costly for performance, and these performance impacts are undesirable.

     A better method, the one that is the focus of this article, solves the problem of determining the problem software function(s) that caused the incorrect counter update. The method is a reference count tracking mechanism (referred from here on as the "tracker") that maintains a running operation-use-history in a table, based on the operation performing the reference count update.

     For example, when the tracker detects operation BBB trying to decrement the counter, but BBB currently doesn't have any active references on the object, the tracker detects this. This can occur before the overall vnode's reference count would attempt to go below 0. At...