On Thu, 8 Apr 2010 13:25:05 -0700 (PDT), Artyom wrote:
__PURE_APPDOMAIN_GLOBAL static std::locale::_Locimp *global_locale = 0; // pointer to current locale
Ok, this is interesting point... Make sure that all DLLs you are using are compiled correctly with Same MSVC runtime **DLL** (with correct import flags) and not mixed DLL/static library/
You were right about that cause of that crash: i had mixed Release and Debug DLLs (that is a problem in its own right as typically you aren't in control of other DLLs)
Ok, I see, this enteres the area called COM+DLLs... where I feel quite... helpless. I really have no idea why this does not work and why something destroyed twice, because it shouldn't.
So reproducing it wasn't too hard after all (once i realised the DLL thing). This code should crash quite reliably: http://www.doc.ic.ac.uk/~awl03/locale_test.zip Turns out its not a COM problem but a general DLL problem
But it looks like rather issue reated to runtime environment rather then to specific localization library.
Basically what happens is that the DLL sets the global locale when it is loaded. Great. We work away doing stuff and everything is fine ... Then at some point the DLL is unloaded. But the global locale is still pointing at an object whose definition was provided by the non-unloaded DLL. Disaster! The next time anything tries to use a locale (like a simple stream op) we crash with an access violation. The problem here is setting a locale 'owned' by the DLL. Is there a way round this? If anyone uses Boost.Locale with COM (or any other situation where DLLs are unloaded) they will run into this problem. Many thanks. Alex