GNOME Bugzilla – Bug 515135
glibmm needs the option not to abort programs with different encodings
Last modified: 2008-03-22 15:13:39 UTC
Currently if Glib::locale_from_utf8() receives different encodings, it aborts in Glib::ConvertError::throw_func. Exception type class ConvertError has no handle. stopped in __exdbg_notify_of_throw Signal ABRT __lwp_kill 0xfcacaa88: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfcacaa98 (dbx) where -h [1] __exdbg_notify_of_throw(0xffbff818, 0xffbff800, 0x1c1c, 0x1c00, 0x160f0, 0xfcd6e004): 0xfcd55a68 [2] _ex_debug_handshake1(0xfcd6e140, 0x0, 0x1, 0x16f68, 0xfcd6d758, 0xfcd6df28): 0xfcd56890 [3] _ex_throw_body(0xfcd6e140, 0x0, 0xffbffc58, 0x16ccc, 0x91918, 0xfcd6e140): 0xfcd56b0c [4] __Crun::ex_throw(0xfcd6e140, 0x1, 0xff1c3820, 0x0, 0xfcd6d758, 0xfcd6df6c): 0xfcd56a68 =>[5] Glib::ConvertError::throw_func(gobject = 0x46760) "convert.cc" [6] Glib::Error::throw_exception(gobject = 0x46760) "error.cc" [7] Glib::locale_from_utf8(utf8_string = CLASS) "convert.cc" [8] main(0x1, 0xffbffcbc, 0x22af0, 0x22800, 0xfadd0, 0xffbffc34): 0x11f98 When we use g_locale_from_utf8(), the error handling is owned by each application. I'ld need the option to avoid that applications always abort with the different encodings. I think we have the case that the actual users' directories have different encoded file contents or file names against the current locale. I'm attaching the patch.
Created attachment 104681 [details] [review] Patch for glib/src/convert.ccg The idea is to use warnings instead of error aboarts. Could you review the patch?
I don't understand why throwing an exception causes an abort. Maybe you could submit a small test case to show that.
Created attachment 105139 [details] Example Test Case I attached the test case. The second locale_from_utf8() or filename_to_utf8() always abort on none UTF-8 locales. Actually I don't know the debugger message "Exception type class ConvertError has no handle.". Thanks.
It does not seem to abort for me: murrayc@murrayc-desktop:~$ g++ test.cc `pkg-config gtkmm-2.4 --libs --cflags` murrayc@murrayc-desktop:~$ ./a.out TRUE Character out of range for UTF-8 Character out of range for UTF-8 (Note to self: Those Character out of range strings are in the test itself.) I am on Ubuntu. What are you using?
> TRUE > Character out of range for UTF-8 > Character out of range for UTF-8 It seems you run the program on UTF-8 locale. Could you try it on ja_JP.eucJP locale? The message "Character out of range for UTF-8" should be localized because glib20.mo has the message. I don't remember Ubuntu has none UTF-8 locales. My platform is Solaris. I invoked "yum install glibmm" on Fedora 8 but it seems no RPMs.
> Could you try it on ja_JP.eucJP locale? Sorry, I don't know how to install that locale on Ubuntu? Do you have any idea? I do have ja_JP.UTF-8.
Maybe you could suggest a different locale that I am likely to have. I'd really like to reproduce this problem.
I could reproduce this problem on Ubuntu 7. % sudo localedef -i fr_FR -f ISO-8859-1 fr_FR.ISO8859-1 % ls /usr/share/locale-langpack/fr/LC_MESSAGES/glib20.mo % env LANG=fr_FR.ISO8859-1 ./test Then the exampl program causes SEGV. Thanks.
Yes, I could reproduce this, though I had to install the regular fr language support in Ubuntu first: murrayc@murrayc-laptop:~/Desktop$ env LANG=fr_FR.ISO8859-1 ./a.out FALSE Caract�re hors des limites UTF-8 terminate called after throwing an instance of 'Glib::ConvertError' Aborted (core dumped) murrayc@murrayc-laptop:~/Desktop$ Here is the backtrace: (gdb) bt
+ Trace 193061
Now I understand that it crashes because you have just not caught the exception. And it should throw an exception because you are trying to convert invalid data. Why not just use catch/try blocks as in this new test case? An exception doesn't have to mean that your application aborts.
Created attachment 107786 [details] test_with_catch.cc
Thanks very much for your time and explanation. I couldn't understand what the debuger meant and which errors should be caught. I'm closing this as "Not a Bug".