Description of problem: Noticed invalid memory access in libfontconfig.so.1.4.4 when using Cairo for generating PDF document. Also reproduced the same program running gnome-about under valgrind (part of messages included many regarding using uninitialized memory are skipped below): ==16607== Invalid read of size 4 ==16607== at 0x3A2D608083: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A447: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61D965: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6130C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6131B5: FcInitLoadConfigAndFonts (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6133D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60882C: FcConfigGetCurrent (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A20F: FcConfigSubstituteWithPat (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x37032093BF: ??? (in /usr/lib64/libpangocairo-1.0.so.0.2904.0) ==16607== by 0x3A30C0AC48: ??? (in /usr/lib64/libpangoft2-1.0.so.0.2904.0) ==16607== by 0x3A33619DE4: ??? (in /usr/lib64/libpango-1.0.so.0.2904.0) ==16607== by 0x3A3361ACF7: pango_itemize_with_base_dir (in /usr/lib64/libpango-1.0.so.0.2904.0) ==16607== Address 0x11738934 is 20 bytes inside a block of size 22 alloc'd ==16607== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==16607== by 0x3A2D607FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A447: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61D965: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6130C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6131B5: FcInitLoadConfigAndFonts (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6133D4: FcInit (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60882C: FcConfigGetCurrent (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A20F: FcConfigSubstituteWithPat (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x37032093BF: ??? (in /usr/lib64/libpangocairo-1.0.so.0.2904.0) ==16607== by 0x3A30C0AC48: ??? (in /usr/lib64/libpangoft2-1.0.so.0.2904.0) ==16607== by 0x3A33619DE4: ??? (in /usr/lib64/libpango-1.0.so.0.2904.0) ==16607== ==16607== Invalid read of size 4 ==16607== at 0x3A2D608098: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A447: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61D965: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2CA0A68A: doContent (xmlparse.c:2449) ==16607== by 0x3A2CA0B8CD: contentProcessor (xmlparse.c:2022) ==16607== by 0x3A2CA0878E: doProlog (xmlparse.c:3908) ==16607== by 0x3A2CA0A11A: prologProcessor (xmlparse.c:3635) ==16607== by 0x3A2CA0D6E1: XML_ParseBuffer (xmlparse.c:1573) ==16607== by 0x3A2D61DAC0: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6130C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6131B5: FcInitLoadConfigAndFonts (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== Address 0x1173ffb0 is 16 bytes inside a block of size 18 alloc'd ==16607== at 0x4A074CD: malloc (vg_replace_malloc.c:236) ==16607== by 0x3A2D607FDC: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D60A447: FcConfigFilename (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61D965: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D61E04D: ??? (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2CA0A68A: doContent (xmlparse.c:2449) ==16607== by 0x3A2CA0B8CD: contentProcessor (xmlparse.c:2022) ==16607== by 0x3A2CA0878E: doProlog (xmlparse.c:3908) ==16607== by 0x3A2CA0A11A: prologProcessor (xmlparse.c:3635) ==16607== by 0x3A2CA0D6E1: XML_ParseBuffer (xmlparse.c:1573) ==16607== by 0x3A2D61DAC0: FcConfigParseAndLoad (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== by 0x3A2D6130C6: FcInitLoadConfig (in /usr/lib64/libfontconfig.so.1.4.4) ==16607== = Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. valgrind --undef-value-errors=no gnome-about 2. 3. Actual results: Error messages like above. Additional error messages from /usr/lib64/gtk-2.0/2.10.0/engines/libqtcurve.so about accessing memory after free(), but it is not related to fontconfig Expected results: Valgrind does not report error messages
I think this has already been fixed in upstream by: http://cgit.freedesktop.org/fontconfig/commit/?id=1c475d5c8cb265ac939d6b9e097666e300162511
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
valgrind error in fontconfig are generally due to valgrind not understanding fontconfigs caches
Re Comment #:1 F16 includes this fix from what I can see. The debuginfo shows the code in the patch that supposidly fixes this upstream. Also note the error is that it is accessing a 4 byte range at byte 20 into block of 22. I would guess that this isn't being allocated inside the method due to the missing symbol "???". I am claiming (with this comment) that the allocation of the memory is not happening inside "FcConfigFileExists" where the patch linked in Comment #:1 to round up the malloc call to a even size of 4 bytes is already included in F16. Therefore it would have been an allocation of 24 bytes if that code path did the allocation, gdb shows the source to have the patch change included in the F16 release but still the same valgrind invalid read-4 output happens as show in the original bug report. My valgrind runs are from May 2012. fontconfig-2.8.0-4.fc16.x86_64 I also do not think this has anything to do with caches the full valgrind backtrace shows up it is part of the configuration parsing and in the methods being called (listed in the valgrind report) the code is mainly manipulating a full pathnames.
(In reply to comment #4) > Re Comment #:1 F16 includes this fix from what I can see. > The debuginfo shows the code in the patch that supposidly fixes this > upstream. That change has been made in 2.9.0. if you doubt you can try it again on rawhide, where 2.9.0 is available.