Part 2 In the first part of this series we looked at how problems emerge when we make the transformation from source code to binary code, and we saw that even when the code is correct errors can be introduced by using dynamic libraries instead of a monolithic binary.

With some simple examples, we’re starting to see problems, using a logically correct C++ program for which we cannot construct a physical representation using dynamic libraries because of platform constraints.

In software security, the industry experts speak of security exposures that occur in the interactions between systems. I think we’re now seeing a similar issue with the interaction of the abstract C++ system and the physical portable executable format system; but instead of a security problem, we get bugs.

Our example comes from real life code, and a large development team that has lived with consequent problems in its Windows environment for a long time, which have cost a lot of money. The issue comes from the interaction of two C++ language features that behave unexpectedly when combined with dynamic linking. We’ll see how on Windows that code packaged in dynamic libraries doesn’t behave in accordance with the C++ language, and we’ll see how to use tools to investigate and resolve the problem. The code we’ll use to expose this insidious problem is shown in the following generic implementation of the Singleton pattern. As we’ll see, this code works fine provided it is not used with dynamic libraries:

// GenericSingleton.hpp
template <typename T>
class GenericSingleton
{
public:
   T &getInstance();

private:
   static T m_instance;
};

template <typename T>
T & GenericSingleton<T>::getInstance()
{
    return m_instance;
}

template <typename T>
T GenericSingleton<T>::m_instance; 

There’s a template class with all of its definitions in the header file. This organisation of a class template is common, perhaps because placing the template definitions in the header file avoids lots of annoying linker warnings. However, as we’ll see, this practice leads to problems once the transition is made from a small monolithic binary program to a modular software system composed of interacting dynamic libraries.

Firstly, why is this code problematic in conjunction with dynamic libraries? There are issues here on Windows and on Linux, but the manifestations of the problems are different.