Bug 214187 - [x86_64] impress crashed when exporting attached file to .ppt
[x86_64] impress crashed when exporting attached file to .ppt
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
6
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 09:11 EST by Scott Tsai
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 2.0.4-5.5.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-14 03:26:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test file (36.32 KB, application/vnd.oasis.opendocument.presentation)
2006-11-06 09:11 EST, Scott Tsai
no flags Details


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

  None (edit)
Description Scott Tsai 2006-11-06 09:11:47 EST
Description of problem:
impress crashed when exporting attached t.odp file to the powerpoint .ppt format.

Version-Release number of selected component (if applicable):
openoffice.org-impress-2.0.4-5.3
openoffice.org-core-2.0.4-5.3

How reproducible:
always

Steps to Reproduce:
1. open attached t.odp
2. "File" -> "Save As" -> "Format: Microsoft ppt"
  
Actual results:
impress crashed (crash dump output pasted below).

Expected results:
correct .ppt file


Additional info:
(I)    x.org loaded video driver of...
(II) Loading /usr/lib64/xorg/modules/drivers/i810_drv.so
(III)  Desktop is: GNOME
(IV)   libgcj version is: libgcj-4.1.1-30-x86_64 libgcj-4.1.1-30-i386
(V)    kernel is: Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006
x86_64 x86_64 x86_64
(VI)   OpenOffice.org core rpm version is: openoffice.org-core-2.0.4-5.3-x86_64
(VII)  depth of root window:    24 planes
(VIII) accessibility is: false
(VIV)  fedora release is: Fedora Core release 6 (Zod)
...start sestatus details ...
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted
...end sestatus details ...
...start stackreport details ...
0x14e36708: /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 + 0x36708
0x14e3718b: /usr/lib64/openoffice.org2.0/program/libuno_sal.so.3 + 0x3718b
0x20dde0: /lib64/libpthread.so.0 + 0xdde0
0x15a6d88c: /usr/lib64/openoffice.org2.0/program/libtl680lx.so + 0x6d88c
(SvStream::SeekPos(unsigned long) + 0x4c)
0x15a6b920: /usr/lib64/openoffice.org2.0/program/libtl680lx.so + 0x6b920
(SvStream::Seek(unsigned long) + 0x50)
0xc89f973f: /usr/lib64/openoffice.org2.0/program/libemp680lx.so + 0xc73f
0xc8a00d72: /usr/lib64/openoffice.org2.0/program/libemp680lx.so + 0x13d72
0xc8a016a1: /usr/lib64/openoffice.org2.0/program/libemp680lx.so + 0x146a1
(ExportPPT + 0x51)
0x2030e4c0: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x30e4c0
0x2025f404: /usr/lib64/openoffice.org2.0/program/libsd680lx.so + 0x25f404
(sd::DrawDocShell::ConvertTo(SfxMedium&) + 0xc4)
0x1c3d4a15: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x1d4a15
0x1c3d7c53: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x1d7c53
0x1c3d83ba: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x1d83ba
0x1c3e28b9: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x1e28b9
0x1c422a1c: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x222a1c
0x1c431518: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x231518
(SfxBaseModel::storeAsURL(rtl::OUString const&,
com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) + 0xc8)
0x1c449019: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x249019
0x1c3e09b2: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x1e09b2
0x1c49d936: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x29d936
0x1c491fca: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x291fca
0x1c4bae6c: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x2bae6c
0x1c4bb7e1: /usr/lib64/openoffice.org2.0/program/libsfx680lx.so + 0x2bb7e1
0x1f33fee5: /usr/lib64/openoffice.org2.0/program/libfwk680lx.so + 0x13fee5
0x1803b1be: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x23b1be
(Menu::Select() + 0x3e)
0x18036af5: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x236af5
0x18099b71: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0x299b71
0xae2ffee7: /usr/lib64/openoffice.org2.0/program/libvclplug_gen680lx.so +
0x57ee7 (SalDisplay::DispatchInternalEvent() + 0xb7)
0xae04b076: /usr/lib64/openoffice.org2.0/program/libvclplug_gtk680lx.so + 0x16076
0x4e2cf44: /lib64/libglib-2.0.so.0 + 0x2cf44 (g_main_context_dispatch + 0x1b4)
0x4e2fd7d: /lib64/libglib-2.0.so.0 + 0x2fd7d
0x4e302ae: /lib64/libglib-2.0.so.0 + 0x302ae (g_main_context_iteration + 0x6e)
0xae04ca9b: /usr/lib64/openoffice.org2.0/program/libvclplug_gtk680lx.so + 0x17a9b
0x17ec8d11: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xc8d11
(Application::Yield(bool) + 0x51)
0x17ec8daa: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xc8daa
(Application::Execute() + 0x2a)
0x1f82bd15: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x2bd15
(desktop::Desktop::Main() + 0x15a5)
0x17ece4d9: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xce4d9
0x17ece5c5: /usr/lib64/openoffice.org2.0/program/libvcl680lx.so + 0xce5c5
(SVMain() + 0x25)
0x1f81ed36: /usr/lib64/openoffice.org2.0/program/libsoffice.so + 0x1ed36
(sal_main + 0x46)
0xff61da44: /lib64/libc.so.6 + 0x1da44 (__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 (0x00002aaaab503000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab707000)
        libstlport_gcc.so =>
/usr/lib64/openoffice.org2.0/program/libstlport_gcc.so (0x00002aaaab921000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002aaaabbfb000)
        libm.so.6 => /lib64/libm.so.6 (0x00002aaaabefd000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002aaaac180000)
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaac38e000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaac6dc000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
...end sample ldd details ...
Comment 1 Scott Tsai 2006-11-06 09:11:47 EST
Created attachment 140476 [details]
test file
Comment 2 Caolan McNamara 2006-11-06 11:57:20 EST
I can reproduce, but only under x86_64. There's something screwy going on with a
SvMemoryStream whose virtual method isn't gett called, but that of the
underlying inherited object.
Comment 3 Caolan McNamara 2006-11-07 05:32:25 EST
grr, ULONG_MAX vs 0xFFFFFFFF and 0 - 1 on x86_64, not sure how we ever even
managed to limp to life in the first place with this. Need to do a test build
for devel and make sure all is well before back to fc-6
Comment 4 Scott Tsai 2006-11-07 05:47:23 EST
Thanks for the hard work.
It's really a shame that no easy to use static analysis tool could help you with
the 64 bit cleanness of the code base.
Just grep the source for 0xFFFFFFFF ?
Comment 5 Caolan McNamara 2006-11-07 05:50:35 EST
some are supposed to be 32bit 0xFFFFFFFF, and some are supposed to be 64bit
ones, the untangling of the two types is the tricky part of the whole operation :-)
Comment 6 Scott Tsai 2006-11-13 19:07:31 EST
openoffice.org-impress-2.0.4-5.5.2 from fc6 updates-testing resolved this
problem for me.

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