Red Hat Bugzilla – Bug 214187
[x86_64] impress crashed when exporting attached file to .ppt
Last modified: 2007-11-30 17: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 ...
Created attachment 140476 [details] test file
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.
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
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 ?
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 :-)
openoffice.org-impress-2.0.4-5.5.2 from fc6 updates-testing resolved this problem for me.