GNOME Bugzilla – Bug 585589
GtkCalendar with LC_TIME specified: Segfault
Last modified: 2009-09-30 20:20:27 UTC
Steps to reproduce: When clicking on the xfce datetime plugin in the xfce panel, xfce4-panel dies with a segmentation fault. In order to reproduce the behavior, I tried glade, with the same result: when you download the minimal glade file attached (only contains a main window and gtkcalendar) and start glade with the locale settings specified, below, I receive a segmentation fault. If I set LC_TIME back to C, glade starts fine. My locate settings: $ locale LANG=C LC_CTYPE="C" LC_NUMERIC=de_AT@euro LC_TIME=de_AT@euro LC_COLLATE="C" LC_MONETARY=de_AT@euro LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL= Seen on a Gentoo Linux amd64 notebook. Stack trace:
+ Trace 215984
Other information:
Created attachment 136454 [details] minimal glade file to reproduce
Update from our downstream bug: ------ Comment #11 From Gilles Dartiguelongue 2009-09-07 19:01:58 0000 [reply] ------- So a null size string is passed to pango which calls strlen which goes crazy because it's null. The selected locale might have a problem, does it fail if you select another locale for your LC_TIME ? ------- Comment #12 From mephinet 2009-09-07 19:17:02 0000 [reply] ------- (In reply to comment #11) > The selected locale might have a problem, does it fail if > you select another locale for your LC_TIME ? Segfault also occurs with LC_TIME=fr_FR and es_ES, with the rest of the LC_* variables left unchanged (as listed in the bug description). If I also set LC_ALL to es_ES or fr_FR, no segfault happens. This might indicate that the bug is only triggered if multiple locales are mixed. ------- Comment #13 From mephinet 2009-09-07 19:21:50 0000 [reply] ------- Further examination shows: if LC_TIME is set to a non-C value, then LC_CTYPE must not be set to C. E.g.: This one segfaults: LC_CTYPE=C LC_TIME=fr_FR (all other) = C This one does not: LC_CTYPE=de_AT LC_TIME=fr_FR (all other) = C
I believe it crashes because we had a packaging bug in some versions of pango (passing of --disable-debug instead of --enable-debug=minimal) and the g_return_val_if_fail (length == 0 || text != NULL) code wasn't included therefore, and it got to go forward and then crash on strlen. However, g_return_val_if_fail is used to catch bad API usage and with --enable-debug=minimal (the default) it will signal a critical warning instead. This still is a problem that warrants fixing
(In reply to comment #3) > I believe it crashes because we had a packaging bug in some versions of pango > (passing of --disable-debug instead of --enable-debug=minimal) and the > g_return_val_if_fail (length == 0 || text != NULL) code wasn't included > therefore, and it got to go forward and then crash on strlen. > > However, g_return_val_if_fail is used to catch bad API usage and with > --enable-debug=minimal (the default) it will signal a critical warning instead. > This still is a problem that warrants fixing Dear Mart, thanks for the hint, when compiling pango without the --disable-debug configure switch, the segfault no longer occurs. Instead, the expected output shows: (glade-3:28484): Pango-CRITICAL **: pango_layout_set_text: assertion `length == 0 || text != NULL' failed