GNOME Bugzilla – Bug 611229
Pango reads from uninitialized memory
Last modified: 2010-03-16 16:56:33 UTC
To reproduce: Font - http://code.google.com/p/liberastika/ Steps: $ pango-view --text="f " --font="Liberastika" Result: $ valgrind pango-view --text="f " ==24886== Memcheck, a memory error detector ==24886== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==24886== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==24886== Command: pango-view --text=f\ ==24886== ==24886== Invalid read of size 1 ==24886== at 0xFED5630: USHORT::operator unsigned short() const (hb-open-type-private.hh:379) ==24886== by 0xFED71BF: Device::get_delta(unsigned int) const (hb-ot-layout-common-private.hh:562) ==24886== by 0xFEDDE17: ValueFormat::apply_value(_hb_ot_layout_context_t*, char const*, SHORT const*, _hb_internal_glyph_position_t*) const (hb-ot-layout-gpos-private.hh:132) ==24886== by 0xFEDF8CF: PairPosFormat1::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:537) ==24886== by 0xFEE010F: PairPos::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:666) ==24886== by 0xFEE1CE3: PosLookupSubTable::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1320) ==24886== by 0xFEE2123: PosLookup::apply_once(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1403) ==24886== by 0xFEE224F: PosLookup::apply_string(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int) const (hb-ot-layout-gpos-private.hh:1426) ==24886== by 0xFEE2487: GPOS::position_lookup(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1473) ==24886== by 0xFED5597: hb_ot_layout_position_lookup (hb-ot-layout.cc:558) ==24886== by 0xFECD2BF: _pango_ot_info_position (pango-ot-info.c:606) ==24886== by 0xFECE427: pango_ot_ruleset_position (pango-ot-ruleset.c:510) ==24886== Address 0x4671275 is not stack'd, malloc'd or (recently) free'd ==24886== ==24886== ==24886== Process terminating with default action of signal 11 (SIGSEGV) ==24886== Access not within mapped region at address 0x4671275 ==24886== at 0xFED5630: USHORT::operator unsigned short() const (hb-open-type-private.hh:379) ==24886== by 0xFED71BF: Device::get_delta(unsigned int) const (hb-ot-layout-common-private.hh:562) ==24886== by 0xFEDDE17: ValueFormat::apply_value(_hb_ot_layout_context_t*, char const*, SHORT const*, _hb_internal_glyph_position_t*) const (hb-ot-layout-gpos-private.hh:132) ==24886== by 0xFEDF8CF: PairPosFormat1::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:537) ==24886== by 0xFEE010F: PairPos::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:666) ==24886== by 0xFEE1CE3: PosLookupSubTable::apply(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1320) ==24886== by 0xFEE2123: PosLookup::apply_once(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1403) ==24886== by 0xFEE224F: PosLookup::apply_string(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int) const (hb-ot-layout-gpos-private.hh:1426) ==24886== by 0xFEE2487: GPOS::position_lookup(_hb_ot_layout_context_t*, _hb_buffer_t*, unsigned int, unsigned int) const (hb-ot-layout-gpos-private.hh:1473) ==24886== by 0xFED5597: hb_ot_layout_position_lookup (hb-ot-layout.cc:558) ==24886== by 0xFECD2BF: _pango_ot_info_position (pango-ot-info.c:606) ==24886== by 0xFECE427: pango_ot_ruleset_position (pango-ot-ruleset.c:510) ==24886== If you believe this happened as a result of a stack ==24886== overflow in your program's main thread (unlikely but ==24886== possible), you can try to increase the size of the ==24886== main thread stack using the --main-stacksize= flag. ==24886== The main thread stack size used in this run was 8388608. ==24886== ==24886== HEAP SUMMARY: ==24886== in use at exit: 172,931 bytes in 1,686 blocks ==24886== total heap usage: 5,750 allocs, 4,064 frees, 802,540 bytes allocated ==24886== ==24886== LEAK SUMMARY: ==24886== definitely lost: 1,039 bytes in 5 blocks ==24886== indirectly lost: 2,936 bytes in 92 blocks ==24886== possibly lost: 85,015 bytes in 739 blocks ==24886== still reachable: 83,941 bytes in 850 blocks ==24886== suppressed: 0 bytes in 0 blocks ==24886== Rerun with --leak-check=full to see details of leaked memory ==24886== ==24886== For counts of detected and suppressed errors, rerun with: -v ==24886== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 5) This is on PPC32, i wasn't able to reproduce it on x86_64 (then again haven't tried with valgrind). Removing (just changing the tag name with a hex editor) kern from the .ttf file "fixes" the issue.
Thanks for the report. I can reproduce this now and mostly understand where the bug is. Will fix tonight or tomorrow.
Ok, I believe I've fixed this bug. Please test and report ASAP since I need to make the release for GNOME 2.30 really soon! [HB] Fix the mystery bug! A couple bugs joined forces to exhibit the mystery behavior of crashes / infinite loops on OS X / wrong kerning / invalid memory access. Pooh! The bugs were involved: - Wrong pointer math with ValueRecord in PairPosFormat1 - Fallout from avoiding flex arrays, code not correctly updated to remove sizeof() usage. We strictly never use sizeof() directly now. And the PairPos code is cleaned up. Should fix them all. Bugs are: Bug 605655 - Pango 1.26.2 introduces kerning bug Bug 611229 - Pango reads from uninitialized memory Bug 593240 - (pangoosx) Crash / infinite loop with Mac OS X We were also doing wrong math converting Device adjustments to hb_position_t. Fallout from FreeType days. Should shift 16, not 6. Fixed that too. There's still another bug: we don't sanitize Device records referenced from value records. Fixing that also.
Unfortunately i can not test it, git version of pango has some requirements which my system doesn't meet (autogen fails due to absence of gtk-doc.m4) Installing gtk-doc is not an option, if there's pre-built configure script which i can use, i would gladly fetch it and give things a try.
I'll make a release in a few days. I can confirm myself that the valgrind errors are fixed by my commit.