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.
Created attachment 40 [details] [review] Debug causes of unset variable in FcFontRenderPrepare
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.
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.
Apart from the FcCompareValueList issue above, please consider this one invalid. I am assuming that purify just screws up over structure argument passing.
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.
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.