The following is a 100% reproducable crash in FontConfig when two applications are used on OS X, one running using FC from an X11 application, and one running with FC from a native Aqua/Cocoa backend (still using libfreetype). Steps to reproduce: 1) Run Inkscape (X11 app) 2) Run Ardour (buit using GTK/OSX) (http://ardour.org/) Steps to "fix" crash: 1) Run Inkscape 2) rm -rf ~/.fontconfig 3) Run Ardour Steps not reproducing crash: 1) Run Ardour 2) Run Inkscape Backtrace (repeatable with FC 2.4.2 through 2.8) # 0 libfontconfig.1.dylib 0x1ef44a85 FcStrListCreate + 51 (fcstr.c:1091) # 1 libfontconfig.1.dylib 0x1ef3d08a FcLangSetHasLang + 193 (fclang.c:388) # 2 libfontconfig.1.dylib 0x1ef3ebfa FcCompareLang + 139 (fcmatch.c:104) # 3 libfontconfig.1.dylib 0x1ef3ef30 FcCompareValueList + 401 (fcmatch.c:325) # 4 libfontconfig.1.dylib 0x1ef3f25c FcCompare + 202 (fcmatch.c:404) # 5 libfontconfig.1.dylib 0x1ef3f9f6 FcFontSetSort + 345 (fcmatch.c:708) # 6 libfontconfig.1.dylib 0x1ef3ff34 FcFontSort + 89 (fcmatch.c:837) # 7 libpangoft2-1.0.0.dylib 0x1ee9d1c1 pango_fc_font_map_load_fontset + 2098 (pangofc-fontmap.c:1076) # 8 libpangoft2-1.0.0.dylib 0x1ee9c8d0 pango_fc_font_map_load_font + 61 (pangofc-fontmap.c:1157) # 9 libpango-1.0.0.dylib 0x1bea9fa5 pango_context_load_font + 55 (pango-context.c:292) # 10 libpango-1.0.0.dylib 0x1beb19e7 pango_layout_get_empty_extents_at_index + 326 (pango-layout.c:4383) # 11 libpango-1.0.0.dylib 0x1beb1fc7 pango_layout_line_get_extents + 736 (pango-layout.c:4423) # 12 libpango-1.0.0.dylib 0x1beb2df0 get_line_extents_layout_coords + 56 (pango-layout.c:2393) # 13 libpango-1.0.0.dylib 0x1beb4d11 pango_layout_get_extents_internal + 339 (pango-layout.c:2507) # 14 libpango-1.0.0.dylib 0x1beb5c54 pango_layout_get_pixel_extents + 80 (pango-layout.c:2648) # 15 libpango-1.0.0.dylib 0x1beb5ccc pango_layout_get_pixel_size + 40 (pango-layout.c:2698) # 16 libgnomecanvas-2.0.dylib 0x1ee637b9 gnome_canvas_text_set_property + 333 # 17 libgobject-2.0.0.dylib 0x1a236e59 g_object_set_property + 1258 (gobjectnotifyqueue.c:145) # 18 libglibmm2.dylib 0x1a63ce32 Glib::PropertyProxy_Base::set_property_(Glib::ValueBase const&) + 56 (propertyproxy_base.cc:126) # 19 Ardour2.bin 0x004a1b06 Glib::PropertyProxy<Pango::FontDescription>::set_value(Pango::FontDescription const&) + 74 (propertyproxy.h:144) # 20 Ardour2.bin 0x004a1b50 Glib::PropertyProxy<Pango::FontDescription>::operator=(Pango::FontDescription const&) + 24 (propertyproxy.h:67) # 21 Ardour2.bin 0x0013eb8a Editor::initialize_canvas() + 836 (editor_canvas.cc:124) # 22 Ardour2.bin 0x000f191a Editor::Editor() + 12430 (editor.cc:469) # 23 Ardour2.bin 0x0003697f ARDOUR_UI::create_editor() + 49 (ardour_ui_ed.cc:70)
I should have noted that we see the two applications creating different content in ~/.fontconfig, since this is not necessarily obvious. Ardour comes with its own fonts.conf file to limit the number of directories searched when building the font cache.
The bug has been fixed in 2.8.0. (In reply to comment #1) > I should have noted that we see the two applications creating different content > in ~/.fontconfig, since this is not necessarily obvious. Ardour comes with its > own fonts.conf file to limit the number of directories searched when building > the font cache. This is evil. If you do that, you should not use ~/.fontconfig. commit 1f4e6fecde22fd4ce8336b01a5c32c533fcb8bac Author: Behdad Esfahbod <behdad@behdad.org> Date: Mon Nov 16 15:39:16 2009 -0500 Bump cache version up from 2 to 3 and fix FcLangSet caching/crash Protect cache against future expansions of FcLangSet (adding new orth files). Previously, doing so could change the size of that struct. Indeed, that happened between 2.6.0 and 2.7.3, causing crashes. Unfortunately, sizeof(FcLangSet) was not checked in fcarch.c. This changes FcLangSet code to be able to cope with struct size changes. And change cache format, hence bumping from 2 to 3.
I tested with a fresh build of 2.8.0 this morning. Crash still occured (the trace was from that build). Why is it so wrong to include a fonts.conf file? We ship fontconfig inside our application - we do not require that users have fontconfig installed. There is no other way for there to be a usable fontconfig conf file without this approach, at least not that I can see.
hang on. are you saying that its fixed in 2.8 but *all* apps that interact with ~/.fontconfig need the update?
as noted, i can demonstrate this crash to you right now, with FC 2.8.0 . if you could clarify what you mean by "fixed", i can test that and identify what is different between our two test cases.
(In reply to comment #3) > I tested with a fresh build of 2.8.0 this morning. Crash still occured (the > trace was from that build). That's impossible. Should be something about your build environment. I bet it's still two pre 2.8.0 versions stepping on eachother's toes. > Why is it so wrong to include a fonts.conf file? We ship fontconfig inside our > application - we do not require that users have fontconfig installed. There is > no other way for there to be a usable fontconfig conf file without this > approach, at least not that I can see. Fine. I just suggested that you should at least change the cache directory to something other than these defaults: <cachedir>/var/cache/fontconfig</cachedir> <cachedir>~/.fontconfig</cachedir> Though, that still shouldn't warrant the crash if at least one of the fontconfigs is 2.8.0. (In reply to comment #4) > hang on. are you saying that its fixed in 2.8 but *all* apps that interact with > ~/.fontconfig need the update? No. Just one of them. And the old caches removed perhaps. (In reply to comment #5) > as noted, i can demonstrate this crash to you right now, with FC 2.8.0 . if you > could clarify what you mean by "fixed", i can test that and identify what is > different between our two test cases. 2.8.0 changes the cache version from 2 to 3. So if you ls ~/.fontconfig you should see files ending with ".cache-3" if you are really using 2.8.0. And previous versions use cache files ending in ".cache-2". They can't be interferring anymore.
I'm closing this since there's been no response.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.