Running the application from gdb, the stack at the time of the crash is as follows: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000001 FcFontSetSort (config=0x0, sets=0xbfffe598, nsets=2, p=0x1a812e0, trim=1, csp=0x0, result=0xbfffe638) at fcmatch.c:696 696 fcmatch.c: No such file or directory. in fcmatch.c (gdb) bt #0 FcFontSetSort (config=0x0, sets=0xbfffe598, nsets=2, p=0x1a812e0, trim=1, csp=0x0, result=0xbfffe638) at fcmatch.c:696 #1 0x018fcad8 in FcFontSort (config=0x0, p=0x1a812e0, trim=1, csp=0x0, result=0xbfffe638) at fcmatch.c:851 #2 0x016669bc in pango_fc_font_map_load_fontset (fontmap=0x1a7fe60, context=0x1a80df0, desc=0x1a810a0, language=0x1a80ef0) at pangofc-fontmap.c:1088 #3 0x005c00a8 in itemize_state_process_run (state=0xbfffe7d8) at pango-context.c:1050 #4 0x005c05e8 in pango_itemize_with_base_dir (context=0x0, base_dir=2413550764, text=0x0, start_index=-1073748580, length=-2077998046, attrs=0x63fefeff, cached_iter=0x1a81040) at pango-context.c:1192 Some more context: fcmatch.c (cvs tag fc-2_3_2), L690-697 nnodes = 0; for (set = 0; set < nsets; set++) { s = sets[set]; if (!s) continue; nnodes += s->nfont; // <---- crash is here } Breakpoint 1, FcFontSetSort (config=0x0, sets=0xbfffe598, nsets=2, p=0x1a812e0, trim=1, csp=0x0, result=0xbfffe638) at fcmatch.c:696 696 nnodes += s->nfont; (gdb) print nsets $6 = 2 (gdb) print sets[0] $7 = (FcFontSet *) 0x1 (gdb) print sets[1] $8 = (FcFontSet *) 0x1 (gdb)
(gdb) print *config $11 = { configDirs = 0x1a82ac0, cache = 0x1a82b70 "/Volumes/Anwenderdaten/Users/aschweiz/.fonts.cache-1", blanks = 0x1a84950, fontDirs = 0x1a82b60, configFiles = 0x1a82b50, substPattern = 0x1a83440, substFont = 0x1a848d0, maxObjects = 3, acceptGlobs = 0x1a830a0, rejectGlobs = 0x0, acceptPatterns = 0x43b2ea27, rejectPatterns = 0x1e, fonts = {0x1, 0x1}, rescanTime = 1, rescanInterval = 27798448 }
I don't understand how this can happen, for a number of reasons; there are a whole bunch of checks that would seem to prevent this from happening in the code. For instance, lines 840-845 should prevent config=0x0 at FcFontSetSort, and config->fonts should never be settable to {0x1, 0x1}. Can you provide any more information?
Closing (inactivity, and I still don't see how it could happen).
This was related to a problem on my side. It looks like the code of the library was loaded twice, and some method invocations were running in the not correctly initialized version. After re-building everything, it works fine.
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.