Red Hat Bugzilla – Bug 240622
x86_64: OO.org (scalc/writer/etc) crashing during startup.
Last modified: 2007-11-30 17:12:04 EST
Description of problem: No idea why/how it began. Seems to have started two days. Tried deleting $HOME/.openoffice but it didn't change anything. Version-Release number of selected component (if applicable): $ rpm -qa | grep openoffice | sort openoffice.org-base-2.0.4-5.5.22.x86_64 openoffice.org-calc-2.0.4-5.5.22.x86_64 openoffice.org-core-2.0.4-5.5.22.x86_64 openoffice.org-debuginfo-2.0.4-5.5.22.x86_64 openoffice.org-draw-2.0.4-5.5.22.x86_64 openoffice.org-graphicfilter-2.0.4-5.5.22.x86_64 openoffice.org-impress-2.0.4-5.5.22.x86_64 openoffice.org-javafilter-2.0.4-5.5.22.x86_64 openoffice.org-langpack-he_IL-2.0.4-5.5.22.x86_64 openoffice.org-math-2.0.4-5.5.22.x86_64 openoffice.org-writer-2.0.4-5.5.22.x86_64 openoffice.org-xsltfilter-2.0.4-5.5.22.x86_64 How reproducible: Always. Steps to Reproduce: 1. Start OO. 2. Crash. Additional info: Related to #226942?
Created attachment 155033 [details] gdb log
Created attachment 155034 [details] pre-crash gdb log. (osl_loadModule -> osl_psz_loadModule. ) " #13 0x00000033c4e2ec04 in osl_psz_loadModule (pszModuleName=0x1 <Address 0x1 out of bounds>, nRtldMode=<value optimized out>) at module.c:136" Without looking into the code, I can't really understand what's going on... but something goes horribly wrong between osl_loadModule and osl_psz_loadModule. Check the gdb session log below. - Gilboa
hmm, most strange, simply looks like it is blowing up on dlopening /usr/lib64/openoffice.org2.0/program/typemgr.uno.so . Perhaps make a backup of that library and extract that lib from the original rpms with cd /tmp/foome && rpm2cpio *core.rpm|cpio -ivd and copy it into /usr/lib64/openoffice.org2.0/program and see if that makes a difference.
I remove the offending openoffice package (openoffice.org-core) and reinstalled it and it seems to be working just fine now. Weird! Any idea what went wrong? - Gilboa
perhaps it was prelink that triggered the problem, it rewrites some libraries. Maybe a manual /usr/sbin/prelink -av -mR to force prelink to happen on the freshly installed .sos might recreate the state OOo was in before the reinstall of the libraries ? If it breaks right after the prelink then this might be the trigger of the problem, otherwise I have no idea.
I re-tried running prelink but didn't see anything blow up. The machine is being used for driver development - it is entirely possible that it crashed while prelink was running, breaking OO. Anyways, thanks for help. - Gilboa
... Should I close the BZ#?