Hi xfce folks, it took me quite some time to figure our why this only happens on one of my boxes: When clicking on the xfce datetime plugin in the xfce panel, xfce4-panel dies with a segmentation fault. Attaching GDB to the process reveals that the segfault comes from libpango. an emerge --emptytree xfce4-panel didn't help. What does help, however, is setting LC_TIME back to "C". My locale setup looks like this (in order to have an english desktop but german date/time/number/currency formatting): 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= de_AT@euro is in my /etc/locate.gen list. Other locale-aware programs are not affected.
Created attachment 193699 [details] output of emerge --info
Created attachment 193701 [details] gdb backtrace of segfault
Interesting, xfce4-panel-4.6.1 will be stabled soon. Maybe that will fix this issue? Otherwise it will need to be filed upstream at http://bugs.xfce.org
(In reply to comment #3) > Interesting, xfce4-panel-4.6.1 will be stabled soon. Maybe that will fix this > issue? Otherwise it will need to be filed upstream at http://bugs.xfce.org No, upgrading to 4.6.1 did not help here. I rebuilt xfce-panel, the plugin, gtk+ and friends with debugging symbols turned on, so now I know that pango_layout_set_text is called from gtk_calendar_size_request with text=0x0, length=-1 as parameters. I'll report upstream.
This is also reproducible with glade, so it's definitely not a xfce-datetime bug, but one of GtkCalendar. Bug report created upstream: <http://bugzilla.gnome.org/show_bug.cgi?id=585589>
thanks.
Adding gtk+ maintainers (see URL).
Could you have a look to http://www.gentoo.org/proj/en/qa/backtraces.xml, then recompile glib and gtk+, and then re-attach a more detailed backtrace ? (missing symbols) Thanks in advance.
(In reply to comment #8) > Could you have a look to http://www.gentoo.org/proj/en/qa/backtraces.xml, then > recompile glib and gtk+, and then re-attach a more detailed backtrace ? > (missing symbols) Sure, I recompiled glib and gtk+ with CFLAGS="-O2 -pipe -march=core2 -ggdb" and splitdebug turned on, and reproduced the bug with glade, by creating a toplevel and adding the calendar widget to it.
Created attachment 203387 [details] glade backtrace improved backtrace attached.
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 ?
(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.
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
As I commented on upstream bug as well: 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 What version of pango were you using at the time it crashed? The packaging bug of pango existed in the 1.24 series up to version 1.24.3. pango-1.24.4 and later should downgrade this crash to a critical warning
(In reply to comment #14) > 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. Dear Mart, you're right, I just re-emerged pango, and now glade-3 no longer segfaults, but shows me the predicted: (glade-3:28484): Pango-CRITICAL **: pango_layout_set_text: assertion `length == 0 || text != NULL' failed > What version of pango were you using at the time it crashed? The packaging bug > of pango existed in the 1.24 series up to version 1.24.3. pango-1.24.4 and > later should downgrade this crash to a critical warning At that time I was using x11-libs/pango-1.24.2. Now that I've upgraded to 1.24.5-r1, which no longer has the $(use_enable debug) , the issue is gone. Thanks for the hint!
