Re: [boost] [Locale] Static locale initialisation

Subject: Re: [boost] [Locale] Static locale initialisation
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-04-10 16:07:47

> > 
> > 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)

So I do not understand fixing correct runtime solved your problem
or not?

> 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
> <snip>
<
> 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.
> 

This code reproduces the issue of crash when you set global locale
and then you do not unload it, at least I see that you
do not call  std::locale::global(std::locale::classic()) . Am I right?

If so.. this is your problem and not Boost.Locale one.

It can be recreated even on Linux with shared objects,
if you create global locale in dynamic library and unload the library
you will crash when you would try to create an locale instance - clearly.

..........

Does it crashes when you call on library unload:

   std::locale::global(std::locale::classic());

If so, are you 100% sure it is called?

Have you triyed to just create a global object with constructor and
destructor (without writing DllMain) -- because it is more portable?

If you cleanup it with:

   std::locale::global(std::locale::classic());

So normal object is created instead of boost.locale

Now there is interesting point. If DLL sets some object owned by dll when
you set std::locale::classic() to global locale... Then blame standard
library, because classic instance should point to standard library runtime
and not DLL and this has nothing to do with Boost.Locale.

If so you may try to set std::locale classic just after unloading library.
If it does not help...

You should not set global locale in loadable module or move to other
platform where dynamically loaded libraries are not so brain-damaged.
(no offense all Windows users :-) )

In any case:

- It seems to be rather standard library issue then Boost.Locale one
- Any DLL that would create its own facets and set global locale would
  have this issue.

Artyom