|Product:||fontconfig||Reporter:||Morten Welinder <mortenw>|
|Component:||library||Assignee:||Keith Packard <keithp>|
|Status:||RESOLVED FIXED||QA Contact:|
|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.