Apache OpenOffice (AOO) Bugzilla – Issue 25492
svdraw/svdobj.cxx issue resulting in infintite loop using up all stack space
Last modified: 2004-02-17 09:37:31 UTC
Hi, This is a regression from 1.1.0, 1.1.1, and 680m15. Matthias Huetsch confirmed this issue on his Linux m25 build and asked me to file this issue and assign it to "graphics" but the closest on the Issues project list seems to be "Draw" which I think owns svx according to the website. If I am mistaken about Draw owning svx, please change the component to the correct one if at all possible. There appears to be a problem in svx/source/svdraw/svdobj.cxx that results in an infinite loop that uses up all available stack space and causes death. The loop in question happens when trying to open up a simple one page survey doc file. The gdb backtrace of the loop looks like the following: The main body of the loop seems to be the following sequence of calls (notice that this is already over 1700 stack frames deep! #1712 0x0ac5a3e8 in SdrObject::SingleObjectPainter(ExtOutputDevice&, SdrPaintInfoRec const& ) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1713 0x0b336518 in cppu::WeakComponentImplHelper2<com::sun::star::document::XEmbeddedObjec tResolver, com::sun::star::container::XNameAccess>::s_cd () from /src4/OpenOffice.org680/program/libsw680lp.so #1714 0x0b3e15d8 in cppu::WeakComponentImplHelper2<com::sun::star::document::XEmbeddedObjec tResolver, com::sun::star::container::XNameAccess>::s_cd () from /src4/OpenOffice.org680/program/libsw680lp.so #1715 0x0ac5a1d0 in SdrObject::DoPaintObject_Wrapper(ExtOutputDevice&, SdrPaintInfoRec cons t&) const () from /src4/OpenOffice.org680/program/libsvx680lp.so #1716 0x0ac459b8 in sdr::contact::ViewContactOfSdrObj::PaintObject(sdr::contact::DisplayInf o&, Rectangle&, sdr::contact::ViewObjectContact const&) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1717 0x0ac4d66c in sdr::contact::ViewObjectContact::PaintObject(sdr::contact::DisplayInfo& ) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1718 0x0ac4d82c in sdr::contact::ViewObjectContact::PaintObjectHierarchy(sdr::contact::Dis playInfo&) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1719 0x0ac4bb94 in sdr::contact::ObjectContactPainter::ProcessDisplay(sdr::contact::Displa yInfo&) () from /src4/OpenOffice.org680/program/libsvx680lp.so .. the loop #1720 0x0ac5a3e8 in SdrObject::SingleObjectPainter(ExtOutputDevice&, SdrPaintInfoRec const& ) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1721 0x0b336518 in cppu::WeakComponentImplHelper2<com::sun::star::document::XEmbeddedObjec tResolver, com::sun::star::container::XNameAccess>::s_cd () from /src4/OpenOffice.org680/program/libsw680lp.so #1722 0x0b3e15d8 in cppu::WeakComponentImplHelper2<com::sun::star::document::XEmbeddedObjec tResolver, com::sun::star::container::XNameAccess>::s_cd () from /src4/OpenOffice.org680/program/libsw680lp.so #1723 0x0ac5a1d0 in SdrObject::DoPaintObject_Wrapper(ExtOutputDevice&, SdrPaintInfoRec cons t&) const () from /src4/OpenOffice.org680/program/libsvx680lp.so #1724 0x0ac459b8 in sdr::contact::ViewContactOfSdrObj::PaintObject(sdr::contact::DisplayInf o&, Rectangle&, sdr::contact::ViewObjectContact const&) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1725 0x0ac4d66c in sdr::contact::ViewObjectContact::PaintObject(sdr::contact::DisplayInfo& ) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1726 0x0ac4d82c in sdr::contact::ViewObjectContact::PaintObjectHierarchy(sdr::contact::Dis playInfo&) () from /src4/OpenOffice.org680/program/libsvx680lp.so #1727 0x0ac4bb94 in sdr::contact::ObjectContactPainter::ProcessDisplay(sdr::contact::Displa yInfo&) () from /src4/OpenOffice.org680/program/libsvx680lp.so ... ditto The problem seems to be that DoPaintObject_Wrapper tries to invoke DoPaintObject but somehow ends up in another DoPaintObject routine somewhere in sw: possibly one of the following weak symbols in libsw*.so [kbhend@base1 lib]$ nm -o libsw*.so | grep DoPaintObject libsw680lp.so:002c1068 t _ZNK12SwFlyDrawObj13DoPaintObjectER15ExtOutputDeviceRK15SdrPaintInfoRec libsw680lp.so:002bf428 t _ZNK13SwDrawVirtObj13DoPaintObjectER15ExtOutputDeviceRK15SdrPaintInfoRec libsw680lp.so:002c13c8 t _ZNK16SwVirtFlyDrawObj13DoPaintObjectER15ExtOutputDeviceRK15SdrPaintInfoRec [kbhend@base1 lib]$ and that somehow ends up re-invoking SingleObjectPainter and the circle starts.. I am able to work around the issue by making the following change to force the DoObjectPaint I expected to be invoked to actually be used. In DoPaintObject_Wrapper else { // call normal old object paint #if 1 sal_Bool res = SdrObject::DoPaintObject(rXOut, rInfoRec); return res; #else return DoPaintObject(rXOut, rInfoRec); #endif } I am not sure why this is happening but the problem occurs on both PPC Linux and x86 Linux on cws_src680_ooo20040225 and m25. I will try to simplify the document in question even more and attach it to this issue. Thanks, Kevin
Created attachment 13136 [details] testcase that recreate problem
Hi, In case it helps, the loop is as follows: In svx: 1. SingleObjectPainter 2. ProcessDisplay 3. PaintObjectHierarchy 4. PaintObject 5. Do PaintObject_Wrapper in sw 6. SwVirtFlyDrawObj::DoPaintObject 7. PaintFlyChilds in svx 8. SingleObjectPainter .... And the loop takes off. So the problem could be in svx or sw I suppose. I can watch the loop happen via debug print statements, but it is simply beyond me to understand where or how this loop should be prevented. Hope this helps, Kevin
I am seeing this (or something ver similar) with M22 on Windows 2003- the moment the word doc has an embedded image OOo dies. Attaching crash report (invoked manully)
Created attachment 13182 [details] windows crashg report
Created attachment 13183 [details] the test file I used
SBA: Prio changed to P2 (Loop). This looks like issue 23500 (Graphics with contour loop when docs are loaded) That issue is fixed in CWS swq03 (integrated in master, build should be available this week). Since I can't tell for sure if that is the one, I won't set this one to duplicate just yet.
Hi, I update my tree with the following /sw/source/core/draw/dflyobj.cxx rev 1.12.72.1 /sw/source/core/view/vdraw.cxx rev 1.11.16.1 /sw/source/core/inc/viewimp.hxx rev 1.23.70.1 And then fixed viewimp.hxx by changing the reference to vcl/color.hxx to use tools/color.hxx to be consistent with this tree. Rebuilt and now all works just fine. So this is a duplicate of Issue 23500 and should be closed as such. I will commit the fixed versions of these files to cws_src680_ooo20040225 so that others doing porting can test their builds with documents that have graphics in them. Thanks, Kevin
AW: OK, thanks for testing this one. I was pretty sure that it is fixed, but i had no time to take a look. So, i set this one to double and close it (if i can, i am not sure...) *** This issue has been marked as a duplicate of 23500 ***
AW: Trying to close...