Bug 242692 - [fix available] impress crashes on StretchAndConvert method and cause X server freeze
[fix available] impress crashes on StretchAndConvert method and cause X serve...
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openoffice.org (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jan Navratil
Depends On:
  Show dependency treegraph
Reported: 2007-06-05 09:54 EDT by Jan Navratil
Modified: 2008-05-21 13:24 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2008-0463
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 13:24:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to avoid crash (1.78 KB, patch)
2007-06-15 05:45 EDT, Caolan McNamara
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 78971 None None None Never

  None (edit)
Description Jan Navratil 2007-06-05 09:54:28 EDT
(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-
(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
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
+ 0xe2)
0x45d41bb8: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741bb8
+ 0x58)
0x45d41aa7: /usr/lib64/openoffice.org2.0/program/libsvx680lx.so + 0x741aa7
+ 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
	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
	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
	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 ...
Comment 3 Caolan McNamara 2007-06-13 10:29:30 EDT
So, from the traces it looks like a huge-ass memory allocation
Comment 4 Caolan McNamara 2007-06-15 04:35:38 EDT
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"
<draw:image xlink:href="./ObjectReplacements/Object 3" xlink:type="simple"
xlink:show="embed" xlink:actuate="onLoad"/>
Comment 5 Caolan McNamara 2007-06-15 05:45:32 EDT
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.
Comment 6 Caolan McNamara 2007-06-15 06:12:23 EDT
So, I checked this workaround into F-7 and devel, and we can do it for a future

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.


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.
Comment 7 Fedora Update System 2007-07-30 12:58:32 EDT
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.
Comment 8 RHEL Product and Program Management 2007-10-15 23:58:29 EDT
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
Comment 10 Caolan McNamara 2007-11-20 08:00:52 EST
in 2.3.0 by virtue of rebase
Comment 14 errata-xmlrpc 2008-05-21 13:24:27 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.