(I) x.org loaded video driver of... (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so (II) Reloading /usr/lib64/xorg/modules/drivers/radeon_drv.so (II) Reloading /usr/lib64/xorg/modules/drivers/radeon_drv.so (III) Desktop is: GNOME (IV) libgcj version is: libgcj-4.1.1-52.el5.2-i386 libgcj-4.1.1-52.el5.2-x86_64 (V) kernel is: Linux 2.6.18-8.1.4.el5 #1 SMP Fri May 4 22:15:17 EDT 2007 x86_64 x86_64 x86_64 (VI) OpenOffice.org core rpm version is: openoffice.org-core-2.0.4-5.4.17.1-x86_64 (VII) depth of root window: 24 planes depth of root window: 24 planes (VIII) accessibility is: false ...start sestatus details ... SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted ...end sestatus details ... ...start stackreport details ... 0x3c4366c8: /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 + 0x366c8 0x3c43714b: /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 + 0x3714b 0x3fa0dd40: /lib64/libpthread.so.0 + 0xdd40 0x3c43a81b: /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 + 0x3a81b (rtl_allocateMemory + 0x9b) 0x44e4e5ff: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x4e5ff 0x44e4e68c: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x4e68c (operator new[](unsigned long) + 0x1c) 0x3f4d502e: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xd502e (StretchAndConvert(BitmapBuffer const&, SalTwoRect const&, unsigned long, BitmapPalette*, ColorMask*) + 0x3de) 0xae2dd897: /usr/lib64/openoffice.org2.0/program/libvclplug_gen680lx.so + 0x30897 0xae2ddb42: /usr/lib64/openoffice.org2.0/program/libvclplug_gen680lx.so + 0x30b42 (X11SalBitmap::ImplDraw(unsigned long, long, SalTwoRect const&, _XGC* const&) const + 0x1a2) 0xae2db1d0: /usr/lib64/openoffice.org2.0/program/libvclplug_gen680lx.so + 0x2e1d0 (X11SalGraphics::drawBitmap(SalTwoRect const*, SalBitmap const&) + 0xb0) 0x3f5ea2a7: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x1ea2a7 (SalGraphics::DrawBitmap(SalTwoRect const*, SalBitmap const&, OutputDevice const*) + 0x97) 0x3f551f64: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x151f64 0x3f552619: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x152619 (OutputDevice::DrawBitmap(Point const&, Size const&, Bitmap const&) + 0x89) 0x40f5da47: /usr/lib64/openoffice.org2.0/program/libsvt680lx.so + 0x15da47 (svt::EmbeddedObjectRef::DrawPaintReplacement(Rectangle const&, String const&, OutputDevice*) + 0x3e7) 0x45e02f85: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x802f85 0x45e06c63: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x806c63 (SdrOle2Obj::DoPaintObject(XOutputDevice&, SdrPaintInfoRec const&) const + 0x2a3) 0x45d39ac7: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x739ac7 (sdr::contact::ViewContactOfSdrObj::PaintObject(sdr::contact::DisplayInfo&, Rectangle&, sdr::contact::ViewObjectContact const&) + 0x87) 0x45d41e65: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741e65 (sdr::contact::ViewObjectContact::PaintObject(sdr::contact::DisplayInfo&) + 0xa5) 0xe036d553: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x16d553 0x45d41b12: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741b12 (sdr::contact::ViewObjectContact::PaintObjectHierarchy(sdr::contact::DisplayInfo&) + 0xe2) 0x45d41bb8: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741bb8 (sdr::contact::ViewObjectContact::PaintDrawHierarchy(sdr::contact::DisplayInfo&) + 0x58) 0x45d41aa7: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741aa7 (sdr::contact::ViewObjectContact::PaintObjectHierarchy(sdr::contact::DisplayInfo&) + 0x77) 0x45d40ff4: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x740ff4 0x45d415a1: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x7415a1 0x45e2d558: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x82d558 (SdrPageViewWindow::Redraw(Region const&, unsigned short, unsigned char const*, sdr::contact::ViewObjectContactRedirector*) const + 0x2c8) 0x45e3037a: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x83037a (SdrPageView::CompleteRedraw(OutputDevice*, Region const&, unsigned short, sdr::contact::ViewObjectContactRedirector*) const + 0x5a) 0x45e37302: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x837302 (SdrPaintView::CompleteRedraw(OutputDevice*, Region const&, unsigned short, sdr::contact::ViewObjectContactRedirector*) + 0x62) 0xe036b3d6: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x16b3d6 0xe05f6197: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x3f6197 0xe05f6cad: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x3f6cad 0xe064d167: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x44d167 0xe0653cb9: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x453cb9 0x3f4ceb60: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xceb60 (Timer::ImplTimerCallbackProc() + 0x80) 0xae059120: /usr/lib64/openoffice.org2.0/program/libvclplug_gtk680lx.so + 0x16120 0x4062d44b: /lib64/libglib-2.0.so.0 + 0x2d44b 0x4062cf44: /lib64/libglib-2.0.so.0 + 0x2cf44 (g_main_context_dispatch + 0x1b4) 0x4062fd7d: /lib64/libglib-2.0.so.0 + 0x2fd7d 0x406302ae: /lib64/libglib-2.0.so.0 + 0x302ae (g_main_context_iteration + 0x6e) 0xae05a9bb: /usr/lib64/openoffice.org2.0/program/libvclplug_gtk680lx.so + 0x179bb 0x3f4c8eb1: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xc8eb1 (Application::Yield(bool) + 0x51) 0x3f4c8f4a: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xc8f4a (Application::Execute() + 0x2a) 0x44e2bbe5: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x2bbe5 (desktop::Desktop::Main() + 0x15a5) 0x3f4ce619: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xce619 0x3f4ce705: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xce705 (SVMain() + 0x25) 0x44e1ec06: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x1ec06 (sal_main + 0x46) 0x3ee1d8a4: /lib64/libc.so.6 + 0x1d8a4 (__libc_start_main + 0xf4) 0x400619: /usr/lib64/openoffice.org2.0/program/simpress.bin + 0x619 ...end stackreport details ... ...start sample ldd details ... libuno_sal.so.3 => /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 (0x00002aaaaaccd000) libuno_salhelpergcc3.so.3 => /usr/lib64/openoffice.org2.0/program/libuno_salhelpergcc3.so.3 (0x00002aaaab0c2000) libstore.so.3 => /usr/lib64/openoffice.org2.0/program/libstore.so.3 (0x00002aaaab2c6000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaab4fa000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab6fe000) libstlport_gcc.so => /usr/lib64/openoffice.org2.0/program/libstlport_gcc.so (0x00002aaaab918000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaabbf5000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaabef5000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaac178000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaac386000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaac6d4000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) ...end sample ldd details ...
So, from the traces it looks like a huge-ass memory allocation
oh dear, the actual file itself contains the offending values, check out the 1.5 kilometer wide and 9.3 kilometer high object <draw:frame draw:style-name="gr98" draw:layer="layout" svg:width="1548550.143cm" svg:height="929628.159cm" svg:x="-27.769cm" svg:y="-10.377cm"> <draw:object-ole draw:class-id="00000000-0000-0000-0000-000000000000" xlink:href="./Object 3" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> <draw:image xlink:href="./ObjectReplacements/Object 3" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame>
Created attachment 157085 [details] patch to avoid crash So attached is a patch which will avoid crashing, but the *real* question is why were such ludicrous values written out on the initial save as.
So, I checked this workaround into F-7 and devel, and we can do it for a future RHEL-5. For Reference: How I debugged this. Just ran in gdb, it crashed in StretchAndConvert, saw it was a huge width causing it, backed up the stackframe and saw it was a huge aRect member in a SdrOleObj. But there was no direct assignment in the bt to that aRect, so added a static int i fprintf(stderr, "%d %x\n", i++, &(aRect.nBottom)); to SdrOleObj::Init and ran in gdb again, this time at the crash I did print &aRect.nBottom and checked the address against the output of the above and saw it was the 9th object, so run in gdb again and put a break point on that fprintf and on the 9th object did watch *(0xFOO) > 1000000 where 0xFoo was the output of print &(aRect.nBottom) for that 9th aRect and then cont gdb stopped OOo when the aRect was assigned the huge value, at that point I could see that the value was assigned from the original xml file through some code in xmloff to handle svg:width , so I unzipped the .odp and searched for svg:width and say the problem was in the original .odp. So: a) we still need to get an example document which we can show to upstream, I propose than Jan apply the patch to a local copy of OOo so it won't crash for him, and then use tools->options->openoffice.org->load/save and uncheck the size optimization (so that the xml is more readable) and then start cutting the document into halves, deleting either the 1st half of the set of slides, or the 2nd set and saving to temp .odps and unzipping them and checking for sillyy svg:widths like above. At some stage we should be able to get it down to a single slide and then scrub manually the content of the slide so that it has nothing we can't show to others in it. That'll be our sample document for reproducing this problem for upstream. b) ideally we could find out *why* we have such a large size for the object, if we have a then we will know which object is the problem and perhaps that'll identify why it might have occurred.
openoffice.org-2.2.1-18.1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
in 2.3.0 by virtue of rebase
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0463.html