odd crash in Font::operator=
erack at redhat.com
Fri Jul 27 14:50:31 PDT 2012
On Friday, 2012-07-27 17:20:58 +0200, Michael Stahl wrote:
> i've had an odd crash in forms_unoapi test yesterday, and can't
> reproduce it; from looking at vcl/source/gdi/font.cxx it appears that
> mpImplFont has been deleted (it can't be 0 apparently).
I see no reason why mpImplFont should point to an already deleted
instance. The only place beside the Font dtor that deletes is operator=
after the line where it crashed..
> #0 0x00002b5293de7280 in Font::operator= (this=0x23a4d98, rFont=...) at /work/lo/master/vcl/source/gdi/font.cxx:679
> #1 0x00002b5293e47963 in OutputDevice::SetFont (this=0x23a4c30, rNewFont=...) at /work/lo/master/vcl/source/gdi/outdev3.cxx:5231
What strikes me is that here in
maFont = aFont;
the maFont _may_ be default constructed unless it was assigned some
other instance before, for example via calls that do a MakeUnique(). If
default constructed the mpImplFont points to the static instance
aStaticImplFont. No idea why mpImplFont or reading from
mpImplFont->mnRefCount should be invalid then, but that's a difference
to "normal" Font objects.
Wild guesses following:
It could be how the static is placed in memory, Impl_Font::mnRefCount is
the first member variable (Impl_Font has no virtual methods and a vptr
should not be present), so if anything immediately before that is
written out of bounds the mnRefCount may suddenly have a value and the
object not be treated as static anymore.
Deleting a static should core dump already, so I don't think that
Placing a memory watch on aStaticImplFont.mnRefCount might reveal
something, with a slim chance..
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the LibreOffice