mjklaim@… — Sun, 15 Apr 2012 10:13:23 GMT

After some hunting:

path::wchar_t_codecvt_facet() always return null
the current implementation of this function is supposed to create/initialize the object it will return;
the current implementation doesn't create/initialize this object if it's not an Apple context (not sure what the macros means here) so any other platform will just return the object pointer without any initialization, that is, undefined behaviour, meaning the pointer is null in debug.
in the case of windows, the object should have been initialized before the function call, as it is defined (in path.cpp) :

#ifdef BOOST_WINDOWS_API
  std::locale path_locale(std::locale(), new windows_file_codecvt);
  const std::codecvt<wchar_t, char, std::mbstate_t>*
    codecvt_facet(&std::use_facet<std::codecvt<wchar_t, char, std::mbstate_t> >
      (path_locale));

I suppose that an assertion checking the pointer in path::wchar_t_codecvt_facet() implementation would be helpful for tests.

I don't have time to go farther, but my understanding is that either:

the object creation returns null (that would be surprising though)
the object creation never occurs.

For this last point, I think that it would be good to check that the compiled code is not the "all posix" one:

#else  // Other POSIX
  // ISO C calls std::locale("") "the locale-specific native environment", and this
  // locale is the default for many POSIX-based operating systems such as Linux.
  // std::locale("") construction can throw (if environmental variables LC_MESSAGES or
  // or LANG are wrong, for example), so lazy initialization is used to ensure
  // that exceptions occur after main() starts and so can be caught.
  std::locale path_locale;  // initialized by path::wchar_t_codecvt_facet() below
  const std::codecvt<wchar_t, char, std::mbstate_t>* codecvt_facet;  // ditto
# endif

Assuming you add an assertion in the function implementation, setting this variable to null would then be very helpful in tests too.

I think I'll have to switch back to the previous boost version for now but I hope you can fin the problem.

status changed

Beman Dawes — Sun, 15 Apr 2012 10:27:10 GMT

status new → assigned

I'm working this issue today. Plan is to (1) revert 76303 and verify that fixes the initialization problems, and then (2) work on fixes to #4889, #6320, codecvt_facet not thread safe on Windows, which will be reintroduced when 76303 is reverted.

--Beman

status changed; resolution set

Beman Dawes — Sun, 15 Apr 2012 20:34:21 GMT

status assigned → closed
resolution → fixed

(In [78000]) Fix #6690 and #6737, resolving static linking related problems with VC++ 8 through 11. Note that this fix may reintroduce codecvt thread safety problems #4889, #6320, for these compilers if static linking is used.

Boost C++ Libraries: Ticket #6690: access violation using global path object

status changed

status changed; resolution set