Access Violation on Static Initialization

Access violation on static initialization

This is the answer of Microsoft as posted to my bug report at Microsoft Connect:

Windows Server 2003 and Windows XP have problems with dynamically loading a DLL (via LoadLibrary) that uses thread-local storage, which is what thread-safe statics use internally to provide efficient execution when the static local has already been initialized. As these systems are out of support, it is extremely unlikely for a patch to be created for those systems to add this support as is present in Vista and newer OSes, and we are reluctant to penalize the performance on in-support OSes to provide this functionality to the old out-of-support ones.

To work around the issue you can use /Zc:threadSafeInit- to disable the thread-safe initialization code and this will avoid the thread-local variable. Of course by doing so the initialization code reverts back to the VS2013 mode and is not thread-safe, so this option is only viable if you don't rely on the thread-safety of local statics.

Access violation when using static std::vector class member

You could just use a meyer's singleton:

instead of:

static std::vector<ATOM> mAtoms;

make a function:

static auto& atoms() {
  static std::vector<ATOM> s;
  return s;
}

Now the vector is initialized on first use. This also affects static destruction order - which may or may not be an issue - but you should be aware of it.

---

Alternatively you could try with an inline initialization - this can likely move the init. up in init. order.

 static inline std::vector<ATOM> mAtoms;

and remove the .cpp init.

---

That being said, it is very likely that it is not that vector causing the heap corruption.

You need to debug heap corruptions.
On windows a good start is _CrtSetDbgFlag

access violation reading location 0x000000004

Where is QuestionName C1Q1:::question_name_ located relative to ClassTemplate::questionName_questionPointer_map_? They seem to be both variables with static storage duration, i.e., they are constructed before main() is run. However, the C++ compiler/linker orders the construction of such global objects only with one translation unit (in which case the objects are constructed top to bottom), not between translation units (in which case the objects are constructed in a random order).

You problem looks as if ClassTemplate::questionName_questionPointer_map would be constructed after C1Q1::question_name_. That is, when C1Q1::question_name_ is constructed, an object which is not, yet, constructed is being accessed.

The conventional fix is to make the static object other objects depend on not an object but rather a function with a local static variable to which a reference is returned:

std::map<QuestionName,ClassTemplete *>&
ClassTemplete::questionName_questionPointer_map_() {
    static std::map<QuestionName,ClassTemplete *> rc;
    return rc;
}

(note that this construction is not thread-safe when you don't use C++11; it is thread-safe when using C++11).

System.UStrClr Access Violation

Related to the static initializer fiascos referred to in numerous other posts on SO, the culprit in this case was the following pattern:

.h file:

class SomeClass {
    static String SOME_STATIC_STRING;
};

String SomeClass::SOME_STATIC_STRING("foo");

If you do elect to use an initializer like this, it should be moved to the .cpp file.

Converting static library to DLL causes access violation before main

I solved the issue by placing both library sources within the same DLL. Our event library actually has macros defined for exporting to a DLL, and we've eliminated any dependency issues by combining the two.

Windows 7 Access Violation

The problem was with boost threads. My static lib uses boost libraries that internally use boost threads. To fix the issue I added a command line define /DBOOST_THREAD_DYN_LINK to both my static library and C++/cli wrapper dll. This means that I had to include the dll files for boost thread, chrono, and system along with my own dll. Why this only happens on Windows 7 and not 10 I am not sure, but I would guess it has to do with the kernel on Windows 7 and how it handles the way boost threads work.

---

Related Topics