Software Diagnostics Institute

In 2015, we introduced patterns-based root cause analysis methodology by adding software problem mechanisms to accompany software diagnostic problems and their analysis patterns. We also planned to start populating the new pattern catalog at that time, but due to other developments and ideas, we have postponed it until now. We also plan to include a new pattern catalog and case studies in our modeling software defects course.

Usually, an identified software diagnostic problem may have several different mechanisms, and a mechanism may contribute to several diagnostic signs and symptoms. Knowing such mechanisms helps greatly in modeling a problem, devising a debugging strategy, and proposing a code fix.

We start with the Spiking Thread memory analysis pattern, which has concrete analysis pattern variants for Windows, Linux, and macOS.

From its Stack Trace, we may identify the source code location. If the code uses some memory-intensive data structure, we may have an instance of Inefficient Container Implementation. Another mechanism to consider is Partial Breaking Functionality. The defect mechanism pattern names are provisional and may change as more patterns are added that require name revisions for generality, consistency, and perhaps just better names.

Inefficient Container Implementation is when a wrong container or flawed implementation is used for memory and CPU-bound code. For example, using a contiguous vector instead of a linked list may affect CPU resource consumption on insertions and deletions. Some containers, such as queues, may use underlying container implementations that can be replaced.

Partial Breaking Functionality is when we have a potentially infinite loop with checks for some conditions that prevent it from running forever. However, the list of such conditions is only partially implemented, leaving some conditions unchecked, which causes a real infinite loop with the detected CPU consumption.