Comment 5 for bug 1377113

Correct, thanks for your comments, I should had a close look.

After closer inspection I suspect that this "Access Violation" probably is happening due to some issue with the proper orchestration of the initialization of static C++ objects. This code "static epicsTimeLoadTimeInit & lti = * new epicsTimeLoadTimeInit ();" is actually following conventional wisdom for how this type of static C++ objects should be instantiated (i.e. the use of new for a static pointer versus the simpler approach of "static epicsTimeLoadTimeInit lti;" which is generally considered to be more likely to cause issues).

However, the issue becomes more complex, and also more unclear in the older c++ standards, when multiple threads are running. Its probably a good idea at this point to obtain an inspection of the current state of the other threads in this process when this happens, and in particular the main thread. Is there some code running before main executes?

As I recall the Visual Studio 2010 has had some known problems in this area, and also possibly that this version of visual studio doesn't use any mutual exclusion to protect the private once-only initialization boolean flag protecting this type of static variables from simultaneous entry into this function by two threads.

I actually wrote some c++ template code implementing compiler specific thread safe protection for initialization of such static variables which exists in some epics work that I completed based on the CVS main trunk, but unfortunately it isn't present in either of the bazaar R3.14 or R3.15 branches.

Also, the C++ 11 standard (and possibly earlier) is quite specific about how mutual exclusion should be provided for such initialization so newer compilers tend to fix this issue. As I recall almost all version of gcc use mutual exclusion to protect this type of intialization, and also perhaps that this issue is fixed in some more recent version of visual c++.

All the best,

Jeff