Bug 70

Summary: FcFontRenderPrepare
Product: fontconfig Reporter: Morten Welinder <mortenw>
Component: libraryAssignee: Keith Packard <keithp>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: 2_1   
Hardware: SPARC   
OS: Solaris   
Whiteboard:
i915 platform: i915 features:
Attachments: Debug causes of unset variable in FcFontRenderPrepare

Description Morten Welinder 2003-04-21 11:54:26 UTC
I see uninitialised memory being read in FcFontRenderPrepare (fcmatch.c:457).

      UMR: Uninitialized memory read (72 times)
      This is occurring while in:
            FcFontRenderPrepare [fcmatch.c:457 pc=0xfb35eec0]
            pango_fc_font_map_get_patterns [pangofc-fontmap.cI:602 pc=0xfa6f91a0]
            pango_fc_font_map_load_font [pangofc-fontmap.cI:632 pc=0xfa6f9278]
            pango_font_map_load_font [pango-fontmap.c:85 pc=0xfa66df8c]
            pango_context_load_font [pango-context.c:222 pc=0xfa66a444]
      Reading 8 bytes from 0xffbeeab8 on the stack (4 bytes at 0xffbeeabc uninit).
      Address 0xffbeeab8 is local variable "v" in function FcFontRenderPrepare.
Comment 1 Keith Packard 2003-04-21 12:20:27 UTC
Created attachment 40 [details] [review]
Debug causes of unset variable in FcFontRenderPrepare
Comment 2 Keith Packard 2003-04-21 12:22:14 UTC
That's very disturbing.  Reading the code, I can't see how that value isn't
getting initialized.  I tried with the attached patch and didn't see the bug
appear.  If you can, please attach the output of from this diff to the bug.
Comment 3 Morten Welinder 2003-04-21 12:44:06 UTC
With the gdb equivalent of the patch, I see no hits.  Note, though, that
FcCompareValueList clearly can return FcTrue yet fail to set *bestvalue.

In this case, it is more likely that an uninitialised value is being copied
into v.  I'll try to track it.
Comment 4 Morten Welinder 2003-04-21 14:00:14 UTC
Apart from the FcCompareValueList issue above, please consider this one invalid.
I am assuming that purify just screws up over structure argument passing.
Comment 5 Keith Packard 2003-04-21 18:10:23 UTC
FcCompareValueList may appear able to return FcTrue without setting *bestValue,
but that would require that one of the two value lists were empty which "can't
happen".  That's why I'm particularily interested in whether this really is a
bug because it would highlight a much more serious problem which would have
widespread implications throughout the library.
Comment 6 Keith Packard 2004-12-04 09:13:07 UTC
Well, this one is sure stale now.  I'm going to assume its been fixed and get on
with life.

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.