3

Alright, I have an exported class within a DLL. This class has a list of static strings, which are used in a ComboBox of a Dialog within the importing process. These strings are declared and defined as follows:

// In header:
class MYDLL_API someClass {
public:
    static const string stringList[];
    static const int numString;
};

// In .cpp
const int someClass::numString = 3;
const string someClass::stringList[numString] = {
    "String 1",
    "String 2",
    "String 3"
};

So the actual exporting works fine. However, I noticed my VS 2008 debugger dumping memory which showed up as

{129} normal block at 0x003D69F0, 32 bytes long.
Data: <String 1>

etc.

So in order to determine who was leaking this memory I stopped using them in the combo Box which they were meant for and checked to see if the leak was still present, it was. So my question is, Is there some issue related to exporting a static class variable from a DLL, where it is considered a memory leak?

1 Answers1

2

This is probably an issue with the order in which the static variables go out of scope and when dlls are unloaded (mfc/crt).

Take a look at this - It describes pretty much the same issue that you're seeing.

There's also a proposed solution here, however I've no idea if this works.

I have had problems like this in the past and the only way I've been able to (cleanly) get rid of these false positives is to define these statics as a shared_ptr and destroy them in a global "shutdown" method.

Alan
  • 13,510
  • 9
  • 44
  • 50