[ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]
|Status:||5 - New|
|Priority:||1 - Request for Enhancement, e.g. asking for a feature|
|Scope:||2 - Specific to an operating system|
|Summary:||Enhance error reporting on broken Xft installations (was:fl_alert dialogs etc crashes in XftTextExtents32 on Solaris)|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
07:13 Jul 07, 2011
|All fl_alert dialogs etc seems to crash on Solaris nowadays: |
Program terminated with signal 11, Segmentation fault.
#0 0xff30bd24 in XftCharIndex () from /usr/lib/libXft.so.2
#1 0xff306a20 in XftTextExtents32 () from /usr/lib/libXft.so.2
#2 0x00091d68 in utf8extents ()
#3 0x00092388 in Fl_Xlib_Graphics_Driver::width(char const*, int) ()
#4 0x0006cf44 in fl_width(char const*, int) ()
#5 0x0008f090 in fl_expand_text(char const*, char*, int, double, int&,
double&, int, int) ()
#6 0x0008f30c in fl_draw(char const*, int, int, int, int, unsigned int, void
(*)(char const*, int, int, int), Fl_Image*, int) ()
#7 0x0008fb04 in fl_draw(char const*, int, int, int, int, unsigned int,
Fl_Image*, int) ()
#8 0x000942f0 in fl_normal_label(Fl_Label const*, int, int, int, int, unsigned
#9 0x00094398 in Fl_Label::draw(int, int, int, int, unsigned int) const ()
#10 0x000944b4 in Fl_Widget::draw_label(int, int, int, int, unsigned int) const
#11 0x0006e464 in Fl_Group::draw_child(Fl_Widget&) const ()
#12 0x0006e654 in Fl_Group::draw_children() ()
#13 0x00062564 in Fl_Window::flush() ()
#14 0x00060d0c in Fl::flush() ()
#15 0x00062904 in Fl::wait(double) ()
#16 0x000629d4 in Fl::wait() ()
#17 0x0008bc04 in innards(char const*, void*, char const*, char const*, char
#18 0x0008c038 in fl_choice(char const*, char const*, char const*, char const*,
I've determined that XftTextExtents32 is called from utf8extents, but it is called with desc->font being zero. This seems to be caused by
fontopen returning zero. XftFontMatch returns a non-null match_pat, but later the XftFontOpenPattern returns zero. Trying to enable:
#if 0 // diagnostic to print the "full name" of the font we actually opened. This works.
...causes the debug printout to segfault.
07:43 Jul 07, 2011
|Output from FcNameUnparse: |
1:minspace=False:charset= |>^1!|>^1!P0oWQ |>^1!|>^1!|>^1!:lang=aa|ast|ay|bi|br|ch|da|eu|fj|fo|fur|fy|gd|gl|gv|ho|ia|id|ie|
The charset looks strange.
06:57 Jul 08, 2011
|Here, under Solaris-SPARC, I see no error when running fl_alert(). |
SunOS xxxxx 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V490
02:07 Jul 11, 2011
|I was building FLTK with MinGW on Linux and testing on: |
SunOS xxx.lkpg.cendio.se 5.10 Generic_141414-08 sun4u sparc SUNW,Sun-Fire-V250
Today, I did a new test, by downloading the pristine 1.3.0 release and building it with the normal build environment shipped with Solaris:
$ export PATH=$PATH:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin:/usr/xpg4/bin:/usr/sfw/bin:
$ ./configure --prefix=/tmp/fltk
$ cd test
$ ./sudoku # Enter a number, then Ctrl-N
Segmentation Fault (core dumped)
(for some unknown reason, the "browser" test was not built)
The backtrace is the same. This machine is:
SunOS xxx 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Blade-1500
The crash happens both with X11 forwarding and on the console.
IOW, this seems to be real problem, happening on different machines with different compilers etc.
02:39 Jul 11, 2011
|This last machine has libXft 2.1.6, according to /usr/openwin/share/include/X11/Xft/Xft.h . If I download & install the latest libXft (2.1.14) and change LD_LIBRARY_PATH before running the demos, the problem goes away. charset still looks strange, though. |
If I manually install libXft 2.1.6, the problem is present. It seems like this is a bug in 2.1.6 which is fixed in later versions. Which version of libXft do you have?
05:28 Jul 11, 2011
|>If I manually install libXft 2.1.6, the problem is present. It seems >like this is a bug in 2.1.6 which is fixed in later versions. |
Correction. I did a mistake when I tested this. My manually installed 2.1.6 also works fine. It's only the libXft that is shipped with Solaris that crashes.
01:49 Jul 20, 2011
|Is it possible that there's a header mismatch on your setup? |
That is, that the libxft that gets linked at runtime (or compile time) does not match the header files built against, or something?
I know I've seen that sort of thing produce behaviours like you describe in the past...
01:23 Aug 03, 2011
|Is there any update on this? |
Are we in a position where we can say whether this is a bug, or just a "feature" of the OP's setup, or...?
01:40 Aug 03, 2011
|It could be a header/library mismatch, but the person that knows more about our build environment is currently on vacation. I can check this out and come back to you in a few weeks. ||
10:13 Sep 27, 2011
|Please let us know if this is still and issue and give us more details. I will close the STR otherwise. ||
01:51 Sep 29, 2011
|I'm hoping I can investigate this further this week. Please hold off a bit before you close it. :) ||
07:04 Sep 29, 2011
|I've determined that this is not a header/library version mismatch at least. I've run the following test software here: |
int main(int argc, char **argv)
printf("Headers: %d\n", XftVersion);
printf("Library: %d\n", XftGetVersion());
And it outputs:
03:55 Sep 30, 2011
|I think he meant that you have an old FLTK header with a newer FLTK library or vice versa. ||
04:43 Sep 30, 2011
|Ah, I see. |
I've done some more investigation though, and FLTK is off the hook (mostly). AFAICT, Solaris' libXft is completely borked when it comes to bitmap fonts. However, they've done some change in the system at some point that makes fontconfig avoid them. So our systems (which are a bit out of date), are picking Serif14.pcf.Z for "Serif", whilst more updated systems are picking "LucidaBrightRegular.ttf".
You can fix the older systems by tweaking the fontconfig settings, at which point it will also choose the Lucida font. You can also see the bad behaviour on new systems by asking for "Gallant", which only exists in a bitmap form.
I haven't been able to figure out exactly what they've managed to do to break their libXft, but I'm not sure it is of any importance.
So this is to a large extent a Solaris bug and not a FLTK one. The thing that FLTK could improve though is to not crash when Xft cannot open a font. Either try to fall back to "Sans", or exit a bit more gracefully with an error message.
13:36 Dec 21, 2011
So... are we going to close this one as "not a fltk bug" and move on, or...
00:49 Dec 22, 2011
|Crashes are always much worse than error messages, so I'm suggesting that we add a simple check for the case when Xft cannot open a font. We can then exit with an error message. ||
20:38 Apr 21, 2012
|A request for enhancement has been raised that we should preferably raise an error dialog when an Xft install is broken instead of a crash. |
A concrete example of enhancement has been suggested when Xft cannot open a font.
[ Return to Bugs & Features | Post Text | Post File ]