Issue 111460 - crash in GraphiteLayout if stlport_debug is active
Summary: crash in GraphiteLayout if stlport_debug is active
Status: ACCEPTED
Alias: None
Product: Build Tools
Classification: Code
Component: external prerequisites (show other issues)
Version: 4.0.0-dev
Hardware: All Windows, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks: 111392
  Show dependency tree
 
Reported: 2010-05-07 16:06 UTC by hdu@apache.org
Modified: 2017-05-20 11:29 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hdu@apache.org 2010-05-07 16:06:33 UTC
AW noticed in issue 111392 a strange crash on a non-product windows build if the bugdoc there was 
loaded and the required fonts were installed on the system.

The problem is that the check GlyphSetIterator::operator!=() is not called if stlport_port debug is active, 
so that the check "gj != charGlyphs.second" in GraphiteLayout::Glyphs::fill_from() is not triggered 
though it should according to the overloaded operator.

The stlport_debug code wraps the GlyphSetIterator and seems to keep its _M_iterator as type "int*" 
instead of a proper GlyphSetIterator, so of course the pointers get then compared directly instead of 
using the proper compare for the GlyphSetIterator.

So the root cause of the problem seems to be the interaction of the used compiler + optimization + 
stlport_debug's iterator wrapper.

@kstribley: we should probably rewrite the problem line graphite_layout.cxx:249 (for DEV300_m77) not 
to drive the compiler so hard. There are other related things such as that operator!= is defined as 
{!(*this==rhs;} and operator*() is overloaded, such that the != case is much more tricky than the 
corresponding operator== case. Especially since the dereference operator*() checks some assertions.
Comment 1 hdu@apache.org 2010-05-07 16:13:57 UTC
Here is a typical crash stack of the scenario described above:

vclmi.dll!_STL::operator==<_...> & __x={...}, const ... & __y={...})  Line 302 + 0x3 bytes
vclmi.dll!GraphiteLayout::Glyphs::fill_from(gr3ooo::Segment&, ImplLayoutArgs&, bool bRtl=false, long & 
rWidth=0, float fScaling=1.0000000, ...)  Line 249 + 0x13 bytes
vclmi.dll!GraphiteLayout::LayoutGlyphs(ImplLayoutArgs&, gr3ooo::Segment*, GrSegRecord*)  Line 795
vclmi.dll!GraphiteWinLayout::LayoutText(ImplLayoutArgs& )  Line 2925 + 0x1d bytes

Since the issue seems to be a compiler problem I'm about to resolve the issue as "invalid for OOo", on 
the other hand I'd be more than happy to accept a patch that would avoid the compiler to be driven 
over its edge.
Comment 2 hdu@apache.org 2010-05-07 16:28:14 UTC
An interesting detail, the operator== called is:
operator==<std::vector::iterator>(
    const DBG_iter_base<std::vector::iterator>&,
    const DBG_iter_base<std::vector::iterator>&)
so the compiler knows that it should use the operator==<DBG_iter_base<std::vector::iterator>>.

On a second look the stlport_debug operator== is defined as
   template <class _Container>
instead of something like 
  template < DBG_wrapped<class _Container>>
Is stlport_debug's equal operator misdefined then?
Comment 3 Marcus 2017-05-20 11:29:39 UTC
Reset assigne to the default "issues@openoffice.apache.org".