| Summary: | access violation in FcFontSetSort | ||
|---|---|---|---|
| Product: | fontconfig | Reporter: | Andreas Schweizer <aschweiz> |
| Component: | library | Assignee: | Keith Packard <keithp> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | blocker | ||
| Priority: | high | ||
| Version: | 2.3 | ||
| Hardware: | PowerPC | ||
| OS: | Mac OS X (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(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.
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)