This crash output appeared in a pop-up window after I had closed a document in Open Office Calc with no other Open Office documents open. This doesn't usually cause a crash. (I) x.org loaded video driver of... (II) Loading /usr/lib/xorg/modules/drivers/i810_drv.so (III) Desktop is: GNOME (IV) libgcj version is: libgcj-4.1.1-51.fc6-i386 (V) kernel is: Linux 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 11:38:26 EDT 2007 i686 i686 i386 (VI) OpenOffice.org core rpm version is: openoffice.org-core-2.0.4-5.5.17-i386 (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: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted ...end sestatus details ... ...start stackreport details ... 0x44e7ee8: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x22ee8 0x44e8b7b: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x23b7b 0xc13420: + 0x420 (__kernel_sigreturn + 0x0) 0x2a70d04: /usr/lib/openoffice.org2.0/program/libsvx680li.so + 0x2dfd04 0x2a70dcc: /usr/lib/openoffice.org2.0/program/libsvx680li.so + 0x2dfdcc 0x2a723f8: /usr/lib/openoffice.org2.0/program/libsvx680li.so + 0x2e13f8 0x388297c: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x4d097c 0x387dce4: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x4cbce4 0x3893442: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x4e1442 0x3888282: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x4d6282 0x394487f: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x59287f 0x38c15f3: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x50f5f3 0x38afdcd: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x4fddcd 0x364cd97: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x29ad97 0x502f1eb: /usr/lib/openoffice.org2.0/program/libsvt680li.so + 0x2eb1eb (SfxUndoArray::~SfxUndoArray() + 0x4b) 0x502f247: /usr/lib/openoffice.org2.0/program/libsvt680li.so + 0x2eb247 (SfxUndoManager::~SfxUndoManager() + 0x37) 0x351483b: /usr/lib/openoffice.org2.0/program/libsc680li.so + 0x16283b (ScDocShell::~ScDocShell() + 0xeb) 0x3a5618: /usr/lib/openoffice.org2.0/program/libtl680li.so + 0x6f618 (SvRefBase::QueryDelete() + 0x18) 0x4be2d83: /usr/lib/openoffice.org2.0/program/libsot680li.so + 0x11d83 (SotObject::QueryDelete() + 0x33) 0x55e889e: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x24c89e 0x55f94cf: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x25d4cf (SfxTopViewFrame::~SfxTopViewFrame() + 0x4f) 0x55f8a11: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x25ca11 (SfxTopViewFrame::Close() + 0x61) 0x55d6a0d: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x23aa0d 0x5602dd7: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x266dd7 (SfxBaseController::dispose() + 0x487) 0x617a4f4: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0x714f4 0x61b2b11: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xa9b11 0x61b34b7: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xaa4b7 0x61b3644: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xaa644 0x4970495: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x2e4495 0x490df96: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x281f96 0xe46351: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x50351 (SalDisplay::DispatchInternalEvent() + 0xb1) 0xc23c66: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xfc66 0xc23ca1: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xfca1 0xa8f6e1: /lib/libglib-2.0.so.0 + 0x296e1 0xa91442: /lib/libglib-2.0.so.0 + 0x2b442 (g_main_context_dispatch + 0x182) 0xa9441f: /lib/libglib-2.0.so.0 + 0x2e41f 0xa94985: /lib/libglib-2.0.so.0 + 0x2e985 (g_main_context_iteration + 0x65) 0xc25b91: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x11b91 0xe477c7: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x517c7 (X11SalInstance::Yield(bool, bool) + 0x37) 0x47216b8: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x956b8 (Application::Yield(bool) + 0x68) 0x472178c: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9578c (Application::Execute() + 0x3c) 0x60d3289: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x26289 (desktop::Desktop::Main() + 0x1779) 0x472725c: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b25c 0x4727365: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x9b365 (SVMain() + 0x35) 0x60c4979: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x17979 (sal_main + 0x59) 0x60c4a04: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x17a04 (main + 0x44) 0x5ccf2c: /lib/libc.so.6 + 0x15f2c (__libc_start_main + 0xdc) 0x80484a1: /usr/lib/openoffice.org2.0/program/scalc.bin + 0x4a1 ...end stackreport details ... ...start sample ldd details ... linux-gate.so.1 => (0x00824000) libuno_sal.so.3 => /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 (0x00bd6000) libuno_salhelpergcc3.so.3 => /usr/lib/openoffice.org2.0/program/libuno_salhelpergcc3.so.3 (0x00b34000) libstore.so.3 => /usr/lib/openoffice.org2.0/program/libstore.so.3 (0x00bad000) libdl.so.2 => /lib/libdl.so.2 (0x00110000) libpthread.so.0 => /lib/libpthread.so.0 (0x00248000) libstlport_gcc.so => /usr/lib/openoffice.org2.0/program/libstlport_gcc.so (0x00114000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00327000) libm.so.6 => /lib/libm.so.6 (0x001e5000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0063e000) libc.so.6 => /lib/libc.so.6 (0x0093b000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x0020c000) /lib/ld-linux.so.2 (0x80000000) ...end sample ldd details ...
caolanm->beland: Can I get the output of readelf -S /usr/lib/openoffice.org2.0/program/libsvx680li.so | grep dynamic and readelf -S /usr/lib/openoffice.org2.0/program/libsc680li.so | grep dynamic please ?
"readelf -S /usr/lib/openoffice.org2.0/program/libsvx680li.so | grep dynamic" produces: [20] .dynamic DYNAMIC 0338c8b0 bfb8b0 0001b0 08 WA 3 0 4 and "readelf -S /usr/lib/openoffice.org2.0/program/libsc680li.so | grep dynamic" produces: [20] .dynamic DYNAMIC 03d8c840 9d9840 0001a0 08 WA 3 0 4
Yeah, same as me. I can see where it crashes, but it can't be a simple NULL pointer given the code in question. So it's not possible to see from the trace why there's a clearly invalid pointer in there, the info as to where things have gone awry originally is not available, and some loading and closing of some calc docs with valgrind doesn't show any obvious problems. We'd need to be able to reproduce this at-will. I don't suppose there's any known way to get this to happen reproducibly ?
Did this crash ever occur again since update 2.0.4-5.5.22 was released for FC-6 ?
Hopefully this was fixed with the last FC-6 update
To answer your earlier question which I somehow overlooked, this has only ever happened once. Thanks for your investigation.