Apache OpenOffice (AOO) Bugzilla – Issue 15237
glpyh cache cleanup oddness ...
Last modified: 2004-01-29 19:13:54 UTC
I just got an OO.o hang, [ linked vs. the system freetype ] - not using any X core fonts; trace appended. It seems slightly odd to me that RemovingGlyph -> GetGlyphID - which seems to generate the glyph itself ;-) Is it the case that X11GlyphPeer::GetGlyphId called from RemovingGlyph needs to handle rGlyphData.GetExtInfo() == EMPTY_KIND - without generating a glyph it is about to destroy ;-) [ a process which I suppose may risk causing re-enterancy problems ] ( although whether this hang is related to that I know not ). HTH. #0 0x40c34567 in malloc_consolidate () from /lib/libc.so.6 #1 0x40c33c95 in _int_malloc () from /lib/libc.so.6 #2 0x40c33394 in malloc () from /lib/libc.so.6 #3 0x403b3b72 in FT_Alloc () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #4 0x403b541b in FT_Outline_New_Internal () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #5 0x403b8163 in FT_Matrix_Invert () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #6 0x403b8441 in FT_Get_Glyph () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #7 0x403afd51 in FreetypeServerFont::GetGlyphBitmap8(int, RawBitmap&) const () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #8 0x4038dfab in X11GlyphPeer::GetGlyphId(ServerFont&, int) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #9 0x4038dba8 in X11GlyphPeer::RemovingGlyph(ServerFont&, GlyphData&, int) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #10 0x403abc1a in ServerFont::GarbageCollect(long) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #11 0x403ab38c in GlyphCache::UncacheFont(ServerFont&) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #12 0x40383fa6 in SalGraphicsData::SetFont(ImplFontSelectData const*) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #13 0x403863af in SalGraphics::SetFont(ImplFontSelectData*) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #14 0x40290b4e in OutputDevice::ImplInitFont() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #15 0x40296c30 in OutputDevice::DrawText(Point const&, String const&, unsigned short, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #16 0x4032bd35 in Edit::ImplRepaint(unsigned short, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #17 0x4032e4a2 in Edit::Paint(Rectangle const&) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #18 0x403036e5 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #19 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #20 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #21 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #22 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #23 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #24 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #25 0x403037e6 in Window::ImplCallPaint(Region const*, unsigned short) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #26 0x4030387e in Window::ImplCallOverlapPaint() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #27 0x40303912 in Window::ImplHandlePaintHdl(void*) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #28 0x403038de in Window::LinkStubImplHandlePaintHdl(void*, void*) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #29 0x4021c2d7 in Timer::Timeout() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #30 0x4021c026 in ImplTimerCallbackProc() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #31 0x40394ba2 in SalData::Timeout() const () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #32 0x4039460d in SalXLib::CheckTimeout(bool) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #33 0x403949fb in SalXLib::Yield(unsigned char) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #34 0x4039d456 in SalInstance::Yield(unsigned char) () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #35 0x402192fb in Application::Yield() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #36 0x4021922b in Application::Execute() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #37 0x0805ff25 in Desktop::Main() () #38 0x4021b64b in SVMain() () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #39 0x4039366c in main () from /usr/lib/ooo-1.0.3/program/libvcl641li.so #40 0x40bdb4ad in __libc_start_main () from /lib/libc.so.6
Created attachment 6621 [details] a fix.
It seems this applies to HEAD just as well as stable; the attached patch is vs. my (slightly old) HEAD snapshot. Hard to say if the performance win is really noticable. HTH.
This patch has been verified to compile with gcc 3.3.
cp->hdu: please have a look at it
Well, a glyph that isn't there will (or should :-) never be garbage collected. If the patch really fixes the problem the same glyph seems to get removed twice. Maybe the question "does a hash_map::erase() invalidate it's iterators?" is true instead of false like the ADT magazine (http://www.adtmag.com/joop/crarticle.asp?ID=850) and the related std::map suggest. Stlport's hash_map does not specify this behaviour... :-( But it is soo On the other hand I have the suspicion that something in XRenderFreeGlyph has problems. It got into xrender very recently and I once in a while saw a crash there. So in HEAD the call got disabled. This isn't much of a leak because the glyhs get freed anyway when the on the local side the ServerFont thus on the XRender side the GlyphSet gets garbage collected. The reentrancy isn't much of a problem yet because we are still protected by the SOLAR_MUTEX. So I'm not sure what to do. If you have a good testcase for the problem that gets fixed by the patch I will happily apply it... Since the call is disabled in HEAD it will not crash there so I will reduce the priority.
Herbert - it may be that a non-existant glyph is never garbage collected; however - if you add a simple fprintf to the case where the glyph is EMPTY_KIND - you will see that several tens of these happen on startup, and in large documents hundreds of instances churn out. ie. this really has a real effect, and it stops glyphs being generated before they are destroyed [ although as you say, now they are not destroyed so ... ] Anyhow, here is a newer patch vs. HEAD.
Created attachment 6645 [details] a more up-to-date patch.
> although as you say, now they are not destroyed so I said they should not be destroyed twice... I will apply the patch and investigate why it happens anyway once an appropriate CWS is opened.
Cannot put in 1.1 will put it in 1.1.01
Got into CWS vcl7pp1r1.
Changing issue type to performance enhancement.
HDU->US: not much to test except that nothing bad happens... Please verify in CWS vcl7pp1r1.
us->hdu: could you pls. try to provide a bit more precise testing hints. * is a test needed in various colour depth [_]? * is a test needed with various FT versions [_]? * is it correct to concentrate on DrawStretchedText [_]?
verified in vcl7pp1r1. Setting resolution to FIXED.
Setting issue to VERIFIED.
.
ok in (internal) master workspace srx645_m27s1-1.8738. Fix will be in forthcoming OOo 1.1.1. Closing Resolved/Verified issue.