GNOME Bugzilla – Bug 692049
Troubles with some locales
Last modified: 2013-03-19 16:56:46 UTC
After setting the variable LANG to "en_US.UTF-8" and starting gparted it exits and I'm getting the following message: (process:381678): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ====================== libparted : 2.3 ====================== (gpartedbin:381678): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: locale::facet::_S_create_c_locale name not valid Trace/breakpoint trap
Can you reproduce this problem? What steps cause this message to appear? Would you be able to try the latest GParted version, currently 0.14.1?
I couldn't find any binary files except the live-files on Sourceforge. GParted 0.12.1 is the latest version in Debian/Ubuntu. The problem is always reproducible. Here is the full terminal output: root@ubuntu:~# LANG=en_US.UTF-8 root@ubuntu:~# gparted (process:383914): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ====================== libparted : 2.3 ====================== (gpartedbin:383914): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: locale::facet::_S_create_c_locale name not valid Trace/breakpoint trap After setting LANG back to "de_DE.UTF-8" GParted is working fine again.
Have you regenerated the locales on Ubuntu so that en_US.UTF-8 is available? You can list the locales with: locale -a See https://help.ubuntu.com/community/Locale
root@ubuntu:~# locale -a C C.UTF-8 de_AT.utf8 de_BE.utf8 de_CH.utf8 de_DE.utf8 de_LI.utf8 de_LU.utf8 POSIX zh_CN.utf8 zh_SG.utf8 The locale en_US.UTF-8 seems to not be available on my system. But shouldn't GParted catch such a problem? All other applications on my system a working fine with such a scenario.
To properly use the en_US.UTF-8 locale with GParted, you will need to generate the en_US.UTF-8 locale. GParted contains no code to check whether the locale is set up correctly. I believe that most other applications are similar in this approach. Closing this bug as NOTABUG.
> I believe that most other applications are similar in this approach. I have tested this now with filezilla, firefox, pidgin, gimp, virtualbox, galculator, keepassx, wireshark and libreoffice. All of these applications are working fine. GParted is the first application after over 2 years which makes troubles on my system with a wrong locale.
Since the en_US.UTF-8 locale is not set up on the computer, it is not possible to "work properly" with the locale. There is no en_US.UTF-8 locale to work with. Instead I suspect that the default "C" locale has simply been chosen.
> Instead I suspect that the default "C" locale has simply been chosen. GParted also fails with the C locale: root@ubuntu:~# LANG=en_US.UTF-8 root@ubuntu:~# LC_ALL=C root@ubuntu:~# gparted (process:409851): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ====================== libparted : 2.3 ====================== (gpartedbin:409851): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: locale::facet::_S_create_c_locale name not valid Trace/breakpoint trap
My apologies. It looks like you have found something here, since the "C" locale is set up on your computer. Re-opening this bug report.
What happens if you issue the following two commands, as root: export LC_ALL=C gparted
This seems to work fine: root@ubuntu:~# LANG=en_US.UTF-8 root@ubuntu:~# export LC_ALL=C root@ubuntu:~# gparted ====================== libparted : 2.3 ====================== But shouldn't get GParted the inherited value of LC_ALL without exporting it?
(In reply to comment #11) > But shouldn't get GParted the inherited value of LC_ALL without exporting it? Environment variables must be exported to pass on to child processes. I believe the failure in comment #8 occurred because the LC_ALL variable was not exported. As a result LC_ALL was not passed on to the "gparted" child process and only the previous "LANG=en_US.UTF-8" was available. We can also check this problem with setup of locale on you computer using perl. Try opening an new terminal window (one without the LC_ALL variable exported), set LANG=en_US.UTF-8, and run the perl interpreter: perl Then CTRL-C out of perl and post the output here.
root@ubuntu:~# LANG=en_US.UTF-8 root@ubuntu:~# perl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). ^C root@ubuntu:~# LC_ALL=C root@ubuntu:~# perl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). ^C Interesting, the LANG variable gets inherited without exporting it but LC_ALL not. But in comment #2 after starting GParted the output shows that the fallback language C will be used but GParted is still exiting.
I can re-produce this on my Fedora 14 and Fedora 17 boxes for locales which don't exist using GParted 0.14.1. # LANG=xx_XX.UTF-8 perl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "xx_XX.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). # LANG=xx_XX.UTF-8 ~mike/bin/gpartedbin (process:20385): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ====================== libparted : 3.1 ====================== (gpartedbin:20385): glibmm-ERROR **: unhandled exception (type std::exception) in signal handler: what: locale::facet::_S_create_c_locale name not valid Trace/breakpoint trap (core dumped) However on Fedora 14 using the GParted 0.7.0 which came with Fedora 14 it doesn't crash. # LANG=xx_XX.UTF-8 /usr/sbin/gpartedbin (process:31987): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ====================== libparted : 2.3 ====================== Doing the same test with gnome-system-monitor (a gtkmm) application doesn't crash either. # ldd /usr/bin/gnome-system-monitor | grep gtk libgtkmm-2.4.so.1 => /usr/lib/libgtkmm-2.4.so.1 (0x0758b000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x0217a000) # LANG=xx_XX.UTF-8 gnome-system-monitor (gnome-system-monitor:32213): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. ** (gnome-system-monitor:32213): WARNING **: SELinux was found but is not enabled. Initial impression is that is seems like a GParted bug introduced after 0.7.0.
I've git bisected the fault to this change: http://git.gnome.org/browse/gparted/commit/?id=a739afc9a1d1d94a8c95446db762db93cff15572 commit a739afc9a1d1d94a8c95446db762db93cff15572 Author: Curtis Gedak <gedakc@gmail.com> Date: Mon Sep 26 16:44:04 2011 -0600 Update String::ucompose library to version 1.0.5 I've tested reverting this change (applied reverse on top of the latest) and it fixes the crash.
(In reply to comment #13) > Interesting, the LANG variable gets inherited without exporting it but LC_ALL > not. But in comment #2 after starting GParted the output shows that the > fallback language C will be used but GParted is still exiting. That's how shells work. A variable only exists once and is either exported or not. When it is updated it still remains exported. The LANG variable will already be set and exported during login, but the LC_ALL variable won't have been set or export. LANG is set and exported. LC_ALL is not. $ set | egrep 'LANG=|LC_ALL=' LANG=en_GB.UTF-8 $ env | egrep 'LANG=|LC_ALL=' LANG=en_GB.UTF-8 Update LANG variable. Its setting changes and it remains exported. $ LANG=xx_XX.UTF-8 $ set | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 $ env | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 Set LC_ALL variable. Its set, but not yet exported. $ LC_ALL=en_US.UTF-8 $ set | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 LC_ALL=en_US.UTF-8 $ env | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 Export LC_ALL variable. $ export LC_ALL $ set | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 LC_ALL=en_US.UTF-8 $ env | egrep 'LANG=|LC_ALL=' LC_ALL=en_US.UTF-8 LANG=xx_XX.UTF-8 Update LC_ALL variable. Its setting changes and it remains exported. $ LC_ALL=en_GB.UTF-8 $ set | egrep 'LANG=|LC_ALL=' LANG=xx_XX.UTF-8 LC_ALL=en_GB.UTF-8 $ env | egrep 'LANG=|LC_ALL=' LC_ALL=en_GB.UTF-8 LANG=xx_XX.UTF-8
Created attachment 233922 [details] [review] Fix locale crash (v1) Hi Curtis, Minimal fix attached. History ... Original bug: Bug #157871 - gparted 0.0.6 segfaults on start First fix: http://git.gnome.org/browse/gparted/commit/?id=a98126d69b176a35ca30bbdb469e84478d76f08d commit a98126d69b176a35ca30bbdb469e84478d76f08d quick 'fix' for crashers in some locales (#157871) basicly the same + Accidentally reintroduced by: http://git.gnome.org/browse/gparted/commit/?id=a739afc9a1d1d94a8c95446db762db93cff15572 commit a739afc9a1d1d94a8c95446db762db93cff15572 Update String::ucompose library to version 1.0.5 Thanks, Mike
Thank you sworddragon2 for persevering with this bug report, and thank you Mike for your great work isolating the problem and locating the original bug report and fix. This bug would have been introduced by me when I upgraded the ucompose library from version 1.0.4 to version 1.0.5. My bad. ;-( Mike's patch from comment #17 has been committed to the git repository for inclusion in the next release of GParted. The relevant git commit can be viewed at the following link: Prevent crash when using an unknown locale (#692049) http://git.gnome.org/browse/gparted/commit/?id=75eba94a6c1620675c01c78119ea9878d6a06856
The code change to address this report has been included in GParted 0.15.0 released on March 19, 2013.