Re: [boost] [Locale] Static locale initialisation

Subject: Re: [boost] [Locale] Static locale initialisation
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2010-04-10 15:18:30

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