std::runtime_error: locale::facet::_S_create_c_locale name not valid

[Gennady Proskurin <gpr@…>]

Try to compile empty program: int main() {} And link it with boost_filesystem

This program will crash throwing exception "std::runtime_error: locale::facet::_S_create_c_locale name not valid" on some systems (FreeBSD and some linuxes) when current locale (LANG,LC_ALL) is not "C"

Systems are known to be affected: DragonFly BSD with boost 1.44 from pkgsrc FreeBSD 7.2-RELEASE with boost 1.44 may be suse linux: Sles 10 sp3 with boost 1.44

Locally, we have to use attached patch as workaround.

[jonathansternberg@…]

This affected my system as well. The attached patch fixed the problem. I'm running Ubuntu 9.04 and used gcc-4.3 to compile. I downloaded the newest release (Boost 1.45.0) that was released today.

Linux aquila 2.6.28-19-generic #66-Ubuntu SMP Sat Oct 16 17:39:04 UTC 2010 i686 GNU/Linux

[Seth Berrier <seth.berrier@…>]

Happens on Solaris 10 (Sun OS 5.10) with gcc-4.2.3 too. Empty program linking against boost_filesystem throws exact same exception. The patch provided fixed the problem.

[anonymous]

Also Ubuntu 10.10 with gcc-4.4.4.

[Sam Morris <sam@…>]

Duplicates in #5100 and #5289 (but with better patches, perhaps).

[anonymous]

Is there any information, when this bug will be fixed? This bug makes boost::filesystem unusable in production environment.

[anonymous]

Still happens with Ubuntu 11.04/g++-4.5.2 and debian with g++/4.4.5. This is a very critical bug for production software as the application can only be started by overriding the locale on the command line (standard C locale seems to work; any other not).

[Beman Dawes]

I've been working on 4688, 5289, 5100, etc. all week. I'll post a status update on the main list, rather than try to reply to each ticket individually.

--Beman

[platima@…]

I've had this same issue with gcc 4.5.2 and 4.5.3 on Ubuntu 8.04 and 10.04.3 (Boost 1.44.0).

Thanks for getting it sorted :)

-Keith

[platima@…]

Oh and that was both i386.

-Keith

[anonymous]

Have you tried 1.47.0?

The critical part of these three issues was fixed, and you should no longer have the problem at startup time.

The issues are about to be closed.

Thanks,

--Beman

[anonymous]

Fixed by changeset 72855, Fix problem of locale("") exception being thrown before main() starts on misconfigured (e.g. LANG="bad name") POSIX systems. Resolves the most serious aspect of tickets 4688, 5100, 5289.

Boost 1.47.0 was the first release to include this fix.

--Beman

[platima@…]

Hey,

Went to give 1.47.0 a shot but had some incompatibilities with our code that need to be addressed.

Thanks -Keith

[gonzalo.raposo@…]

I tried it with boost 1_47 but is still happen the same on FreeBSD 8.1, doesn't work with locale en_US.UTF-8 nor with C (which was working with boost 1_46_1).

There was some compatibility issues (private functions that before were public and boost::asio::const_buffer_1 doesn't accept std::string anymore as constructor's parameter)

[platima@…]

Hey,

Yeah we're having the same issues reported by multiple people with 1.47.0.

We've had to force LC_ALL=C in our launcher to avoid it, but this really isn't a nice way about it.

Any thoughts/suggestions? Thanks -Keith

[anonymous]

Replying to gonzalo.raposo@…:

I tried it with boost 1_47 but is still happen the same on FreeBSD 8.1, doesn't work with locale en_US.UTF-8 nor with C (which was working with boost 1_46_1).

What is the "it" you are trying? Could you post code that fails?

And exactly what happens? Are you saying that the app still throws an exception before main starts?

Thanks,

--Beman

[anonymous]

Replying to anonymous:

Replying to gonzalo.raposo@…:

I tried it with boost 1_47 but is still happen the same on FreeBSD 8.1, doesn't work with locale en_US.UTF-8 nor with C (which was working with boost 1_46_1).

What is the "it" you are trying? Could you post code that fails?

And exactly what happens? Are you saying that the app still throws an exception before main starts?

Thanks,

--Beman

Yes, it means that the app is still trowing the exception before main starts when locale != C. What you need to reproduce this issue is just create a simple main that uses boost.filesystem and the locale is another than C (en_US.UTF-8 for example)

Gonzalo

[mihai.dontu@…]

Replying to anonymous:

Replying to anonymous:

Replying to gonzalo.raposo@…:

I tried it with boost 1_47 but is still happen the same on FreeBSD 8.1, doesn't work with locale en_US.UTF-8 nor with C (which was working with boost 1_46_1).

What is the "it" you are trying? Could you post code that fails?

And exactly what happens? Are you saying that the app still throws an exception before main starts?

Thanks,

--Beman

Yes, it means that the app is still trowing the exception before main starts when locale != C. What you need to reproduce this issue is just create a simple main that uses boost.filesystem and the locale is another than C (en_US.UTF-8 for example)

Gonzalo

I have came across the same problem, only I am using a cross compiler. The true issue lies in how GCC (libstdc++) is configured. On some Linux distributions and apparently FreeBSD, the C++ runtime is configured to use generic locale support. This is the one that handles nothing but "C". However, if one configures GCC with "--enable-clocale=gnu", a more advanced implementation becomes available. I don't know if it's tied in any way to the GNU C library (it doesn't appear to) and I also don't know the proper way to check if you have "generic" or "gnu" enabled. I used

$ objdump -D -C -j .text -M intel libstdc++.so.6 >libstdc++.so.6.S

to look in the assembler dump for _S_create_c_locale(). A call to "newlocale@plt" tells me I have "gnu" enabled.

[anonymous]

boost filesystem patch to include FreeBSD in the list of BSD platforms (!) that need locale fix

[charles@…]

I see this on Solaris 11 as well in boost 1.52

[ruipfernandes@…]

Same problem in HPUX with gcc44

[bapt@…]

same patch for boost 1.52.0

[Beman Dawes]

(In [83083]) Add FreeBSD support. Fix #4688

[hours10000@…]

I have came accoss the same problem . GCC 4.1.0 SUSE LINUX 10.1 (x86-64) VERSION =10.1

[hours10000@…]

Replying to hours10000@…:

I have came accoss the same problem . GCC 4.1.0 SUSE LINUX 10.1 (x86-64) VERSION =10.1

PS; boost 1.53

[ruipfernandes@…]

Replying to bemandawes:

(In [83083]) Add FreeBSD support. Fix #4688

This change (83083) is not totally correct. As you can see in the patch by bapt added at 6 February, there are three lines where the change should be done, however only two of them were changed in this changeset. I also figured out that for HP-UX a similar procedure solves the problem.

Please do replace the following string (three occurrences):

defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__)

with this one:

defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) || defined(__FreeBSD__) || defined(__hpux)

I'd also like to point out another fix I asked (misspelled macro name _INCLUDE_STDC__SOURCE_199901), related to ticket #5048 (I added a comment to the ticket)

Thank you very much.

[Beman Dawes]

Replying to hours10000@…:

Replying to hours10000@…:

I have came accoss the same problem . GCC 4.1.0 SUSE LINUX 10.1 (x86-64) VERSION =10.1

PS; boost 1.53

You need to test against svn trunk. The fix changeset was applied after 1.53 shipped.

--Beman

[Beman Dawes]

Replying to ruipfernandes@…:

Replying to bemandawes:

(In [83083]) Add FreeBSD support. Fix #4688

This change (83083) is not totally correct. As you can see in the patch by bapt added at 6 February, there are three lines where the change should be done, however only two of them were changed in this changeset.

The current svn trunk, which is what the fix was applied against, has only two occurrences.

I also figured out that for HP-UX a similar procedure solves the problem.

Please do replace the following string (three occurrences):

defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__)

with this one:

defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) || defined(__FreeBSD__) || defined(__hpux)

I'm nervous about adding HP-UX. Are you sure that all HP-UX systems use UTF-8 encoding? Do you have a link to HP docs on that?

I'd also like to point out another fix I asked (misspelled macro name _INCLUDE_STDC__SOURCE_199901), related to ticket #5048 (I added a comment to the ticket)

I'll take a look. Thanks,

--Beman

[hendrich@…]

Complete fuckup. Setting any LANG makes Ubuntu unusable. On my 12.04:

export LANG=de export LANG=en_US export LANG=en_US.UTF-8

makes every subsequent program crash with the boost crazyness.

[anonymous]

Happens to me as well, using Boost 1.55.0.

[anonymous]

Using boost 1.52 on gentoo, I got the same error message. Google landed me here.

I had LANG=en_US.UTF-8. Doing unset LANG and then re-running my application worked.

[Marcin Konarski <marcin.konarski+boost@…>]

Replying to hendrich@…:

Complete fuckup. Setting any LANG makes Ubuntu unusable. On my 12.04:

export LANG=de export LANG=en_US export LANG=en_US.UTF-8

makes every subsequent program crash with the boost crazyness.

You are quite wrong, Ubuntu 12.04 has boost version 1.48 which already has this bug fixed. Still your application may crash but if it does it is bug in your application and not in boost, bug which coincidentally manifests itself the same way.

Original bug in boost was an exception thrown in initialization of global object, which happened before main() and hence was (almost) impossible to handle in programmatic way.

Since forementioned initialization was turned into lazy initialization, the same exception, which by the way is quite valid, can be handled programmaticaly.

This bug should be marked as fixed.

[Beman Dawes]

std::runtime_error: locale::facet::_S_create_c_locale name not valid exceptions may be caused by Boost.Filesystem errors, user program errors, or user system configuration errors. Comments on this thread mixed all three types of errors, making the thread hard to parse.

Please do not reopen this thread. Please open a new issue if you encounter a Boost.Filesystem error in 1.56.0 and it is not already described in another open filesystem issue. Please include a test program that illustrates the error, with instructions as to how to build and execute the program. Please do not bother to report locale and codecvt related errors in versions prior to 1.56.0 unless they also occur in 1.56.0, which made important changes locale and codecvt handling.

Thanks,

--Beman