Modify

Ticket #4688 (reopened Bugs)

Opened 4 years ago

Last modified 2 months ago

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

Reported by: Gennady Proskurin <gpr@…> Owned by: bemandawes
Milestone: To Be Determined Component: filesystem
Version: Boost 1.52.0 Severity: Showstopper
Keywords: Cc:

Description

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.

Attachments

boost_filesystem.patch Download (934 bytes) - added by Gennady Proskurin <gpr@…> 4 years ago.
boost_filesystem.2.patch Download (934 bytes) - added by Gennady Proskurin <gpr@…> 4 years ago.
boost_1_47_0_filesystem_freebsd.patch Download (2.5 KB) - added by anonymous 2 years ago.
boost filesystem patch to include FreeBSD in the list of BSD platforms (!) that need locale fix
patch-boost-filesystem-str_runtime Download (1.4 KB) - added by bapt@… 15 months ago.
same patch for boost 1.52.0

Change History

Changed 4 years ago by Gennady Proskurin <gpr@…>

Changed 4 years ago by Gennady Proskurin <gpr@…>

comment:1 Changed 3 years ago by 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

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by anonymous

Also Ubuntu 10.10 with gcc-4.4.4.

comment:4 Changed 3 years ago by Sam Morris <sam@…>

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

comment:5 Changed 3 years ago by anonymous

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

comment:6 Changed 3 years ago by 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).

comment:7 Changed 3 years ago by bemandawes

  • Status changed from new to assigned

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

comment:8 Changed 3 years ago by 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

comment:9 Changed 3 years ago by platima@…

Oh and that was both i386.

-Keith

comment:10 Changed 3 years ago by 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

comment:11 Changed 3 years ago by anonymous

  • Status changed from assigned to closed
  • Resolution set to fixed

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

comment:12 Changed 3 years ago by platima@…

Hey,

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

Thanks -Keith

comment:13 follow-up: ↓ 15 Changed 3 years ago by 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)

comment:14 Changed 3 years ago by 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

comment:15 in reply to: ↑ 13 ; follow-up: ↓ 16 Changed 3 years ago by 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

comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 3 years ago by 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

comment:17 in reply to: ↑ 16 Changed 3 years ago by 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.

Changed 2 years ago by anonymous

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

comment:18 Changed 15 months ago by charles@…

I see this on Solaris 11 as well in boost 1.52

comment:19 Changed 15 months ago by ruipfernandes@…

  • Status changed from closed to reopened
  • Version changed from Boost 1.44.0 to Boost 1.52.0
  • Resolution fixed deleted

Same problem in HPUX with gcc44

Changed 15 months ago by bapt@…

same patch for boost 1.52.0

comment:20 follow-up: ↓ 23 Changed 14 months ago by bemandawes

  • Status changed from reopened to closed
  • Resolution set to fixed

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

comment:21 follow-up: ↓ 22 Changed 14 months ago by hours10000@…

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

comment:22 in reply to: ↑ 21 ; follow-up: ↓ 24 Changed 14 months ago by 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

comment:23 in reply to: ↑ 20 ; follow-up: ↓ 25 Changed 13 months ago by 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.

comment:24 in reply to: ↑ 22 Changed 13 months ago by bemandawes

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

comment:25 in reply to: ↑ 23 Changed 13 months ago by bemandawes

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

comment:26 follow-up: ↓ 27 Changed 7 months ago by hendrich@…

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Severity changed from Problem to Showstopper

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.

comment:27 in reply to: ↑ 26 Changed 2 months ago by anonymous

Happens to me as well, using Boost 1.55.0.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.