[ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #2676

Trouble Report Files:

No files

Trouble Report Comments:

	Name/Time/Date	Text
	#1  astrand 07:13 Jul 07, 2011	All fl_alert dialogs etc seems to crash on Solaris nowadays: Program terminated with signal 11, Segmentation fault. Backtrace: #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 int) () #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 const*) () #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.
	#2  astrand 07:43 Jul 07, 2011	Output from FcNameUnparse: Match: Serif-14:style=Serif:slant=0:weight=200:width=100:pixelsize=14:spacing=100:found ry=Sun:antialias=False:hintstyle=3:hinting=True:verticallayout=False:autohint=Fa lse:globaladvance=True:index=0:outline=False:scalable=False:dpi=72:rgba=1:scale= 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| io|is|lb|mg|nb|nds|nn|no|nr|oc|om|rm|sma|smj|so|sq|ss|st|sv|sw|ts|vo|wa|xh|yap|z u:fontversion=0:fontformat=PCF:embolden=True:embeddedbitmap=True:decorative=Fals e The charset looks strange.
	#3  manolo 06:57 Jul 08, 2011	Here, under Solaris-SPARC, I see no error when running fl_alert(). uname -a SunOS xxxxx 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-V490
	#4  astrand 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: /usr/X11/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.
	#5  astrand 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?
	#6  astrand 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.
	#7  ianmacarthur 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...
	#8  ianmacarthur 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...?
	#9  astrand 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  matt 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.
	#11  ossman 01:51 Sep 29, 2011	I'm hoping I can investigate this further this week. Please hold off a bit before you close it. :)
	#12  ossman 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: #include <X11/Xft/Xft.h> int main(int argc, char **argv) {         printf("Headers: %d\n", XftVersion);         printf("Library: %d\n", XftGetVersion());         return 0; } And it outputs: bash-3.00# ./xfttest Headers: 20106 Library: 20106
	#13  matt 03:55 Sep 30, 2011	I think he meant that you have an old FLTK header with a newer FLTK library or vice versa.
	#14  ossman 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.
	#15  ianmacarthur 13:36 Dec 21, 2011	OK. So... are we going to close this one as "not a fltk bug" and move on, or...
	#16  astrand 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.
	#17  fabien 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 ]