Created attachment 395077 [details] oowriter backtrace Description of problem: Summary say it all. Backtrace attached, doc file also. Version-Release number of selected component (if applicable): openoffice.org-core-3.1.1-19.5.el5-x86_64 How reproducible: 30% Steps to Reproduce: 1. 2. 3. Actual results: oowriter crash Expected results: oowriter shouldn't crash Additional info:
Created attachment 395078 [details] doc file
I cannot reproduce the crash and the stack is too generic to see the reason for it. Anyway, it doesn't look like it crashed on loading a doc file. dtardon->tpelka: What does that 30% mean? That you opened the file three times and it crashed once? Or that it crashes approximately on every third try to open it? In other words, can you reproduce it?
Created attachment 395091 [details] mapped stack
This sort of looks like http://qa.openoffice.org/issues/show_bug.cgi?id=93187 though that was supposed to be fixed in 3.0. If it is reproducible, even 30% of time then perhaps a strace -f on /usr/lib64/openoffice.org/soffice.bin blah.doc on a session that does crash be useful
Created attachment 395456 [details] strace out It is reporducable especialy after reboot for me. As root seems that works fine.
Created attachment 395459 [details] ooo stack trace Sorry wrong one before, here is the right one.
This is somewhat baffling. I think the immediate throw that causes the crash should only happen if the toplevel frame was disposed, so the question is why does OOo close itself down. And *sometimes* but not always. There are rather too many routes to guess. The last thing in the strace before death is just scanning the dictionaries. Might as well a) give us the output of ls /usr/lib/openoffice.org/share/dict/ooo just in case. If as root it always works fine it might be something in your ~/.openoffice.org config dir, but then I'd expect it to happen every time as that user. Nevertheless b) tar czf /tmp/config.tar.gz ~/.openoffice.org* and attach config.tar.gz here
(In reply to comment #7) > This is somewhat baffling. > > I think the immediate throw that causes the crash should only happen if the > toplevel frame was disposed, so the question is why does OOo close itself down. > And *sometimes* but not always. There are rather too many routes to guess. The > last thing in the strace before death is just scanning the dictionaries. Might > as well > > a) give us the output of ls /usr/lib/openoffice.org/share/dict/ooo just in > case. ls -m /usr/lib64/openoffice.org/share/dict/ooo en_AG.aff, en_AG.dic, en_AU.aff, en_AU.dic, en_BZ.aff, en_BZ.dic, en_CA.aff, en_CA.dic, en_GB.aff, en_GB.dic, en_GH.aff, en_GH.dic, en_IE.aff, en_IE.dic, en_IN.aff, en_IN.dic, en_JM.aff, en_JM.dic, en_NA.aff, en_NA.dic, en_NZ.aff, en_NZ.dic, en_PH.aff, en_PH.dic, en_TT.aff, en_TT.dic, en_US.aff, en_US.dic, en_ZA.aff, en_ZA.dic, en_ZW.aff, en_ZW.dic, hyph_en_AG.dic, hyph_en_AU.dic, hyph_en_BZ.dic, hyph_en_CA.dic, hyph_en_GB.dic, hyph_en_GH.dic, hyph_en_IE.dic, hyph_en_IN.dic, hyph_en_JM.dic, hyph_en_NA.dic, hyph_en_NZ.dic, hyph_en_PH.dic, hyph_en_TT.dic, hyph_en_US.dic, hyph_en_ZA.dic, hyph_en_ZW.dic, README_en_AU.txt, README_en_CA.txt, README_en_GB_thes.txt, README_en_GB.txt, README_en_US.txt, README_en_ZA.txt, README_hyph_en_CA.txt, README_hyph_en_GB.txt, README_hyph_en_US.txt, README.txt, th_en_AG_v2.dat, th_en_AG_v2.idx, th_en_AU_v2.dat, th_en_AU_v2.idx, th_en_BZ_v2.dat, th_en_BZ_v2.idx, th_en_GH_v2.dat, th_en_GH_v2.idx, th_en_IE_v2.dat, th_en_IE_v2.idx, th_en_IN_v2.dat, th_en_IN_v2.idx, th_en_JM_v2.dat, th_en_JM_v2.idx, th_en_NA_v2.dat, th_en_NA_v2.idx, th_en_NZ_v2.dat, th_en_NZ_v2.idx, th_en_PH_v2.dat, th_en_PH_v2.idx, th_en_TT_v2.dat, th_en_TT_v2.idx, th_en_US_v2.dat, th_en_US_v2.idx, th_en_ZA_v2.dat, th_en_ZA_v2.idx, th_en_ZW_v2.dat, th_en_ZW_v2.idx > > If as root it always works fine it might be something in your ~/.openoffice.org Nothing changed compared to default settings. > config dir, but then I'd expect it to happen every time as that user. > Nevertheless > > b) tar czf /tmp/config.tar.gz ~/.openoffice.org* and attach config.tar.gz here will attache in next comment
Created attachment 395468 [details] config
I see it.
Hmm! output of rpm -q db4 please ? I see that ~/.openoffice.org/3/user/uno_packages/cache/uno_packages.db is version 9. I would expect it to be version 8 on RHEL-5.
(In reply to comment #11) > Hmm! output of > rpm -q db4 > please ? > db4-4.3.29-10.el5 > I see that ~/.openoffice.org/3/user/uno_packages/cache/uno_packages.db is > version 9. I would expect it to be version 8 on RHEL-5. Ahaa know where could be the problem, sometimes I mount my $HOME also in F12/rhel6, maybe ooo.org from F12/rhel6 may change this. Will try to remove ~/.openoffice.
Seems it helped. No crash. After reboot also no crash. We could close this issue as NOTABUG, if you are OK with it?
Created attachment 395508 [details] fix for this
Nah, we'll hold on to it. We shouldn't crash anyway. And 3.2 includes a fix for this sort of thing.
*** Bug 604963 has been marked as a duplicate of this bug. ***
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.