Created attachment 49478 [details] open the file, change one letter and close the file - crash as an attachment there is a writer file. open it, change one letter and save it. Closing the writer file libO crashes. somewhat in the text causes the crash, it cannot be seen. tested with windows 7-64.
I see the crash also with 3.4.1-rc3 on Linux. I checked the 64-bit build on SLED11-SP1-x86_64.
can reproduce with -3-4-2 rc2 on Linux; needs some valgrinding of writer I think.
The code nearest to the crash, seems to have been there since 2000 ... Program received signal SIGSEGV, Segmentation fault. 0xae62db28 in SwTxtFrm::IsLocked (this=0x0) at /data/opt/libreoffice/libreoffice-3-4/clone/writer/sw/source/core/inc/txtfrm.hxx:383 383 inline sal_Bool IsLocked() const { return bLocked; } (gdb) bt #0 0xae62db28 in SwTxtFrm::IsLocked (this=0x0) at /data/opt/libreoffice/libreoffice-3-4/clone/writer/sw/source/core/inc/txtfrm.hxx:383 #1 0xae65d68b in SwFtnBossFrm::RemoveFtn (this=0xac6c0168, pRef=0xac5e1b44, pAttr=0x8ae3f40, bPrep=1 '\001') at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ftnfrm.cxx:1906 #2 0xae7a9dad in SwTxtFtn::DelFrms (this=0x8ae3f40, pSib=0xac5e1ab4) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/txtnode/atrftn.cxx:381 #3 0xae6b0ad6 in SwCntntFrm::~SwCntntFrm (this=0xac5e1ab4, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ssfrm.cxx:492 #4 0xae78628a in SwTxtFrm::~SwTxtFrm (this=0xac5e1ab4, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/text/txtfrm.cxx:404 #5 0xae7862e5 in SwTxtFrm::~SwTxtFrm (this=0xac5e1ab4, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/text/txtfrm.cxx:408 #6 0xae6b11b3 in SwLayoutFrm::~SwLayoutFrm (this=0xac6c20c8, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ssfrm.cxx:607 #7 0xae685ff8 in SwBodyFrm::~SwBodyFrm (this=0xac6c20c8, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/clone/writer/sw/source/core/inc/bodyfrm.hxx:37 #8 0xae686039 in SwBodyFrm::~SwBodyFrm (this=0xac6c20c8, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/clone/writer/sw/source/core/inc/bodyfrm.hxx:37 #9 0xae6b11b3 in SwLayoutFrm::~SwLayoutFrm (this=0xac6c00f0, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ssfrm.cxx:607 #10 0xae62f590 in SwFtnBossFrm::~SwFtnBossFrm (this=0xac6c00f0, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/clone/writer/sw/source/core/inc/ftnboss.hxx:57 #11 0xae67fc06 in SwPageFrm::~SwPageFrm (this=0xac6c00f0, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/pagechg.cxx:278 #12 0xae67fc61 in SwPageFrm::~SwPageFrm (this=0xac6c00f0, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/pagechg.cxx:318 #13 0xae6b11b3 in SwLayoutFrm::~SwLayoutFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ssfrm.cxx:607 #14 0xae679dca in SwRootFrm::~SwRootFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/newfrm.cxx:606 #15 0xae679e3b in SwRootFrm::~SwRootFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/newfrm.cxx:624 #16 0xae9622b5 in boost::checked_delete<SwRootFrm> (x=0x8b42e40) at /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/inc/boost/checked_delete.hpp:34 #17 0xae962e24 in boost::detail::sp_counted_impl_p<SwRootFrm>::dispose (this=0x8b42ef8) at /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/inc/boost/smart_ptr/detail/sp_counted_impl.hpp:78 #18 0xae3ef73a in boost::detail::sp_counted_base::release (this=0x8b42ef8) at /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/inc/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145 #19 0xae3ef79e in boost::detail::shared_count::~shared_count (this=0x8b3fb80, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/inc/boost/smart_ptr/detail/shared_count.hpp:217 #20 0xae961c12 in boost::shared_ptr<SwRootFrm>::~shared_ptr (this=0x8b3fb7c, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/solver/340/unxlngi6.pro/inc/boost/smart_ptr/shared_ptr.hpp:169 #21 0xae961941 in ViewShell::~ViewShell (this=0x8b3fb28, __in_chrg=<value optimized out>) ---Type <return> to continue, or q <return> to quit--- at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/view/vnew.cxx:275 #22 0xae3fe322 in SwCrsrShell::~SwCrsrShell (this=0x8b3fb28, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/crsr/crsrsh.cxx:2600 #23 0xae5acd59 in SwEditShell::~SwEditShell (this=0x8b3fb28, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/edit/edws.cxx:66 #24 0xae600530 in SwFEShell::~SwFEShell (this=0x8b3fb28, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/frmedt/fews.cxx:704 #25 0xaec87482 in SwWrtShell::~SwWrtShell (this=0x8b3fb28, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/ui/wrtsh/wrtsh1.cxx:1759 #26 0xaec87513 in SwWrtShell::~SwWrtShell (this=0x8b3fb28, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/ui/wrtsh/wrtsh1.cxx:1767 #27 0xaebd2a71 in SwView::~SwView (this=0x8b57908, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/ui/uiview/view.cxx:1073 #28 0xaebd2e03 in SwView::~SwView (this=0x8b57908, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/ui/uiview/view.cxx:1088 #29 0xb77f52cf in ?? () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so #30 0xb77f5f94 in SfxViewFrame::~SfxViewFrame() () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so #31 0xb77f60d8 in SfxViewFrame::~SfxViewFrame() () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so #32 0xb77f5e8d in SfxViewFrame::Close() () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so #33 0xb77dfeb2 in ?? () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so #34 0xb77efa0f in SfxBaseController::dispose() () from /data/opt/TTInstall/program/../basis-link/program/libsfxli.so I suppose it may be related to the re-factor of the layout fun that we merged in m104: commit bee0ab39bd38fc866e4e7149b9ac59b6a0209b63 Author: Mathias Bauer <mba@openoffice.org> Date: Fri Dec 17 09:02:23 2010 +0100 CWS swlayoutrefactoring: #i115510#: first step to clean up the SwClient mess Which at least changed FindMaster's function. Unfortunately, reproducing it is not so easy as it was at first for me. Perhaps it relies on the layout code being in a given state when we exit. The banal patch: --- a/sw/source/core/layout/ftnfrm.cxx +++ b/sw/source/core/layout/ftnfrm.cxx @@ -1897,7 +1897,7 @@ void SwFtnBossFrm::RemoveFtn( const SwCntntFrm *pRef, const SwTxtFtn *pAttr, { OSL_ENSURE( pRef->IsTxtFrm(), "NoTxtFrm has Footnote?" ); SwTxtFrm* pMaster = (SwTxtFrm*)pRef->FindMaster(); - if( !pMaster->IsLocked() ) + if( pMaster && !pMaster->IsLocked() ) pMaster->Prepare( PREP_FTN_GONE ); } } Might fix the symptom, if not the underlying problem, but lots of other FindMaster results are used unchecked. Thoughts appreciated.
Any thoughts Cedric ? :-)
Created attachment 49536 [details] Modified file without crash
That seems to be similar to 'Bug 39447 - Writer crashes at closing a document with footnotes in a single paragraph over two pages'. The attached 'temp-49_modified.odt' doesn't crash at closing. My modification: Inserted a manual page break on page 3 after "xxhöhxwgew dxx xmsayzsyexxx (zxleyzy 1.1.2007, 1.4.1998) sqwd sowsy wqchy awzxseyzew, da qw dew fesygesyellyew waxprxcsqwdqces ewyhalyew." [highlighted yellow]. All footnotes of the former single paragraph are now in a second paragraph on page 4.
No Crash with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" No Crash with "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]", so REGRESSION OS -> All due to Comment 2
*** Bug 39647 has been marked as a duplicate of this bug. ***
Within relative short time we had DUPs Bug 39427, Bug 39447, Bug 39647, what shows the severity of this bug. Currently LibO is unusable for scientific texts or other ones with many footnotes. This is even more serious because users suffering from an other footnote problem (Bug 37974, Bug 38052, Bug 38291 (all fixed for 3.4.2?)) can not upgrade. So I decided to rate this one as a blocker. Please feel free to downgrade Importance if you see higher-ranking interests to get released 3.4.2 asap.
I also saw the crash with a daily build nearby "LibreOffice 3.4.1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:101)]"
Adding my humble opinion, I fully agree to rate this as a blocker. Particularly the less technically experienced researchers are afraid of having lost data due to this bug (I can name at least two plus myself). This cannot be unfixed in 3.4.2 particularly if it should be ready for enterprise and professional deployment.
Created attachment 49761 [details] patch for debugging the issue I debugged a bit around this. The issue after all is that the assertion at: http://opengrok.libreoffice.org/xref/writer/sw/source/core/layout/flowfrm.cxx#698 fires: "Follow ist lost in Space." I created the attached debug code to see when things go wrong: - After loading, the doc looks sane - After inserting a char the doc looks sane - After saving, the doc looks sane - At the start of SwView::~SwView() the doc looks sane So the issue is likely that the destruction of the layout does something in the wrong order while destructing itself. To use the patch (which is never intended to be commited obviously), apply it, compile sw with "make DBGLEVEL=2" and type: p debug_checkCntntNodeFollow(debug_GetLastLoadedDoc()) in gdb. The debugcode needs some more tuning to work well during destruction, because it gets the RootFrm from the SwDoc, which is disconnected rather early. HTH a bit.
I could to really figure out what is going on there, but this looks really, really wrong: #14 0xae679dca in SwRootFrm::~SwRootFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/newfrm.cxx:606 #15 0xae679e3b in SwRootFrm::~SwRootFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/newfrm.cxx:624 To me that looks like the SwRootFrm thinks it is a member of itself. It calls its own destructor on the same instance (itself) upon leaving the scope of the destructor. While I think that cant be right, it can be even less right with the SwRootFrm being owned by the ViewShell (via boost::shared_ptr<>), so the only one ever calling a ~SwRootFrm destructor should be that shared_ptr<>. Unfortunately, I havent figured it out completely -- all I see is that I jump from the last line of the destructor to the first one of it in the debugger. Most likely the cause is somewhere in writer:0382ef89c6631ec39b98b63dbdadd85ecea11275, but that one is not-so-small.
Created attachment 49762 [details] patch for debugging the issue updated patch to check the consistency of the layout. Im giving up for now (after all it is weekend and vacation for me).
Ok, one final suspicion: at #13 0xae6b11b3 in SwLayoutFrm::~SwLayoutFrm (this=0x8b42e40, __in_chrg=<value optimized out>) at /data/opt/libreoffice/libreoffice-3-4/sw/source/core/layout/ssfrm.cxx:607 http://cgit.freedesktop.org/libreoffice/writer/tree/sw/source/core/layout/ssfrm.cxx?h=libreoffice-3-4-2#n607 the SwLayoutFrm has already been removed from the layout tree in the line before, so when FindMaster iterates backwards through the tree it cant find its Master, because that is in the other tree. Dunno why this would have worked before then though (maybe by some evil Doc->IsInDtor() magic?)
(In reply to comment #9) > So I decided to rate this one as a blocker. Please feel free to downgrade > Importance if you see higher-ranking interests to get released 3.4.2 asap. I see the crash also with LO-3.4.0-final on SLED11-SP1-x86_64 => it is an older bug. Nobody escalated it earlier, so it can't block the 3.4.2 release. We are sorry but affected users need to wait for LO-3.4.3 release. BTW: The crash happens when people close the document. It usually happens when people close the whole application => It is ugly, it might block saving other opened documents but it should not cause that much harm in most cases.
Created attachment 49780 [details] structure of the layout at the beginning of destruction and at the time of crash In the attached file, you will find a representation of the layout at the beginning of the destruction and which frms are already deleted at the crash. You will find that the text frame 0x7fffc1fb4228 is already removed from the layout but still has a follow, the text frame 0x7fffc1fb4330, that is still in the layout. When it tries to delete 0x7fffc1fb4330, 0x7fffc1fb4330 tries to find its master by iterating backwards through the layout, which must fail. I am still unsure why this does not happen in 3.3.3 -- that might be worth a look. However, in general the solution seems to be to remove all footnotes before a textframe gets removed at sw/source/core/layout/ssfrm.cxx:606 ...
*** Bug 39447 has been marked as a duplicate of this bug. ***
*** Bug 39861 has been marked as a duplicate of this bug. ***
If can help, in the attachment if you up one level the first heading, then don't crash.
*** Bug 39899 has been marked as a duplicate of this bug. ***
*** Bug 39925 has been marked as a duplicate of this bug. ***
*** Bug 40092 has been marked as a duplicate of this bug. ***
Created attachment 50269 [details] Crashlog from Mac OS X 10.7
It can be reproduced on Mac OS X 10.7 in LO 3.4.2 Release. Crashlog added.
Hi, is the fix for this bug planned to go into 3.4.3? @Petr: referring to your comment 16, there are several reasons to rate this bug as a release blocker, although it might be 'alive' for quite some while. Reasons: First, the bug can definitively result in data loss. How to reproduce: (1) Open attached document by gerdl, (2) make minor changes to the document and save it, (3) open any other document and make changes to it, but don't save it, (4) close the first document. -> Result: LibreOffice crashes and all changes to the second document are lost. Second, the bug already has seven duplicates Third, it affects many documents (containing footnotes), not only few. Please reconsider your decision not to five this bug a 'blocker' status. Thanks.
Three more points of advocacy, I'll be brief: 1. Users may be under-reporting this bug because there is no indication the crash/recovery cycle is due to footnotes or endnotes. I had a difficult time tracing it to this bug. In fact, the crash does not seem like a crash. WinXP does not give the usual crash response. The program just closes after closing a document, which would be normal in MS Word. 2. Users may be under-reporting this bug because they are still on the 3.3 branch. 3. Almost all academic publishing uses footnotes, or more commonly, endnotes. All my documents crash, so far.
(In reply to comment #27) > Three more points of advocacy, I'll be brief: > > 1. Users may be under-reporting this bug because there is no indication the > crash/recovery cycle is due to footnotes or endnotes. I had a difficult time > tracing it to this bug. In fact, the crash does not seem like a crash. WinXP > does not give the usual crash response. The program just closes after closing a > document, which would be normal in MS Word. > > 2. Users may be under-reporting this bug because they are still on the 3.3 > branch. > > 3. Almost all academic publishing uses footnotes, or more commonly, endnotes. > All my documents crash, so far. I would stronly support these tree points. I have lots of dokuments with footnotes. For this reason I have gone back to 3.3 branch.
FindMaster crasher remembers me of something I fixed a while ago: http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc3d0d182cafef9649e45f4657233ac2221fdd0a I can't remember for sure the cause of this hack... and I'll try it on 3.4 to see if it fixes the crasher.
(In reply to comment #29) > FindMaster crasher remembers me of something I fixed a while ago: > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc3d0d182cafef9649e45f4657233ac2221fdd0a > > I can't remember for sure the cause of this hack... and I'll try it on 3.4 to > see if it fixes the crasher. Tested to backport this patch on 3.4: works nicely with it. Bjoern, do you have any concern with this patch?
No objections against that patch. It is much saner than what we had before.
I don't know anything to the contrary to make me thing its a bad idea anyway :-)
Patch pushed in both 3-4 and 3-4-3 branches. http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4-3&id=9ad0a499e48f959184e4add6dcc65ba289e36470 http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=68b27b713285ddee7b44bb9f57e01066e28eb1b1
*** Bug 40331 has been marked as a duplicate of this bug. ***
so a big applause for diving into this and fixing it guys :-)
(In reply to comment #33) > Patch pushed in both 3-4 and 3-4-3 branches. > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4-3&id=9ad0a499e48f959184e4add6dcc65ba289e36470 > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=68b27b713285ddee7b44bb9f57e01066e28eb1b1 Super job done - tanks a lot everybody!
Fix confirmed in LibreOffice 3.4.3 rc2 (Ubuntu 10.04 x86_64). Thanks again. JBF
(In reply to comment #33) > Patch pushed in both 3-4 and 3-4-3 branches. > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4-3&id=9ad0a499e48f959184e4add6dcc65ba289e36470 > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=68b27b713285ddee7b44bb9f57e01066e28eb1b1 Fix confirmed in LibreOffice 3.4.3 rc2 (Win Vista SP2)
Fix confirmed in LibreOffice 3.4.3 rc2 for Mac OS X (tested on Mac OS X 10.7.1) (In reply to comment #33) > Patch pushed in both 3-4 and 3-4-3 branches. > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4-3&id=9ad0a499e48f959184e4add6dcc65ba289e36470 > > http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=68b27b713285ddee7b44bb9f57e01066e28eb1b1
I just installed 3.4.3 on Ubuntu natty to try if it works and, alas, LO still crashes on my footnoted files. I doesn'r crash every time so things are definitely better, but this bug is still far from resolved. Have you tried other formats with footnotes? (i.e. doc that is still the most popular exchange format) Many thanks
@krzysztof pijarski Could you provide a sample document?
Created attachment 51098 [details] bug not fixed for this file Crash problem exists for this file. I am running 3.4.3.2 on Pardus Linux.
No crash on closing for me. LibO 3.4.3 under Win7 Italian 64 bit.
(In reply to comment #42) > Created an attachment (id=51098) [details] > bug not fixed for this file > > Crash problem exists for this file. I am running 3.4.3.2 on Pardus Linux. no crash on closing for me Vista HP SP2 // LO 3.4.3 OOO340m1 (Build:302)
No crash with Bertan Gündoğdu' sample and with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]". @Bertan Gündoğdu: Please mention that a crashing document with footnotes does not inevitably mean that the fix does not work. I future please report your observations if it's your suspect that the fix does not work, but do not touch "the dashboard"! @Jeffry or someone else: can you please do a test with Linux?
I reproduce the crash with the testfile from Bertan Gündoğdu under Ubuntu 10.04 x86_64. I did same test as with the first testfile by gerdl: - open the file with LibO 3.4.3 (build 302) - change one letter - save the file - close the file by clicking on the top right cross (do not close LibO, only the file) ==> crash (LibO close without notice, then launch LibO and get the restoration dialog) No crash with the testfile from gerdl. Best regards.JBF
Created attachment 51163 [details] odt file with footnotes that crash
(In reply to comment #47) > Created an attachment (id=51163) [details] > odt file with footnotes that crash This file "odt file with footnotes that crash", continuously crashes LO 3.4.3 in Win XP when I open it. I worked on this file without any problems UNTIL I copied some lines from a docx file with footnotes to it. Then all of a sudden this file caused LO to crash. This also happenned to a file with footnotes that I converted into from docx into odt format. Just open the file in LO.
@Rainer In BUG#40092, İsmail attached two versions of the file that i attached to this bug and a simplified version is here [1]. In that bug report, it is accepted that the simplified version of the file causes the same crash, thus the bug is marked as a dup. Hope this helps. [1] https://bugs.freedesktop.org/attachment.cgi?id=50225 "more simple buggy odt file"
I can reproduce the crash wit Asterix'x test document and "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]". When I increase page hight of that document to 60cm the crash disappears, when I return to A4 the crash reappears. It seems that this bug has some more reasons and aspects that were not visible with the first sample document. @Cédric: Can you please examine these new aspects? Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Bug reproduced with the test file from Astrix ("Finale Chapter 2 draft 1.odt") and with LibreOffice 3.4.3 final (OOO340m1 (Build:302)) under MacOS X 10.6.8 German. Just following nearly the same steps as mentioned by Jean-Baptiste Faure: 1) open the file with LibO 3.4.3 (build 302) 2) change one letter 3) save the file 4) close the file by clicking on the window's top left (red) button (note that this will close the just file, not the application, under MacOS) ==> Crash: The system's window "Error Report for LibreOffice" with the message "LibreOffice wurde unerwartet beendet" (LibreOffice was quitted unexpectedly) appears. I will attach the MacOS X crashlog. Hope it helps a little bit ...
Created attachment 51329 [details] The MacOS X 10.6.8 crashlog when closing the sample document from Astrix The MacOS X 10.6.8 crashlog when closing the sample document from Astrix, copied from the window "Error Report for LibreOffice" presented by the OS after the crash. If you need some other log files, let me know ...
(In reply to comment #50) > I can reproduce the crash wit Asterix'x test document and "LibreOffice 3.4.3 > RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]". > > When I increase page hight of that document to 60cm the crash disappears, when > I return to A4 the crash reappears. > > It seems that this bug has some more reasons and aspects that were not visible > with the first sample document. > > @Cédric: > Can you please examine these new aspects? > Please feel free to reassign (or reset Assignee to default) if it’s not your > area or if provided information is not sufficient. Please set Status to > ASSIGNED if you accept this Bug. If it helps to increase the importance of this bug ;) I've got the same problem. My system environment is: MS Windows XP SP3 German (all updates), LibreOffice 3.4.3 It took me a while to trace my problems with the not removed lock files and the document recovery back to this bug. (It didn't seem likely that this bug might be caused by footnotes) I'm working on a document which will be about 100 pages or more by the time it will be finished. It contains around 60 footnotes at the moment and if I do it right this number will increase! (I didn't attach this file, since it is almost 700k. I will work on a stripped down version of this file if it helps.) This file has been first set up with OpenOffice 3.2.1 and I've made every upgrade that has been released up to LibreOffice 3.4.3 For scientific purposes I think it is extremely critical (I was about to say: ludicrously critical) that footnotes (or anything else for that matter) will not cause crashes! When do you think this bug will be fixed? (Not pushing; just looking for information, since I put work on this document on hold because of this bug) Thank you in advance Fabian
The odt file I added "odt file with footnotes that crashed" did not cause any crashes until I copied parts of a docx file with footnotes into it. I was wondering whether bug 39179 could have any thing to do with this bug. Bug 39179 is about writer taking around 2 minutes to open a 50 page docx file with footnotes and 6 minutes to open a 100 page docx file with footnotes.
Created attachment 51524 [details] patch killing footnotes first Attached patch seems to fix the problem. It makes the layout remove all footnotes as first step before proceeding killing the rest. I will commit it to master and put it for review on -3-4.
pushed to master as: http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac1912ecb13709082026428d2b2a56c4915b939f
Submitted for review for backporting to -3-4: http://nabble.documentfoundation.org/REVIEW-3-4-fdo-39510-crash-on-closing-document-with-footnotes-td3359414.html
(In reply to comment #56) > pushed to master as: > http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac1912ecb13709082026428d2b2a56c4915b939f Fix confirmed with nightly build -- LibO-dev 3.5.0 (Build ID: 3323ab3-c56b83c-1e62dcb-2c8122e-7a7d02) running on MacOS X 10.6.8 --: the sample document provided by Astrix doesn’t crash LibreOffice anymore, neither after the simple steps mentioned by Jean-Baptiste Faure or myself, nor after playing around a bit with the document and especially with the footnotes. @ Björn Michaelsen: thank you very much! @ Bertan Gündoğdu & @ Astrix: could you test your crashing files with a new nightly build, just to make sure that all manifestations of the footnotes related crash are fixed now?
backported to 3-4 for 3.4.4 release with: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=f8f5d96666bff5051cc88d06b10d855548a441de http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=6a3faed5b459ea133c39ef5243dad8e366ca00c3
(In reply to comment #59) > backported to 3-4 for 3.4.4 release [...] Many thanks! So all users will benefit from you patch soon (the publishing date for 3.4.4 is Nov 9, 2011, if I recall correctly).
Fix confirmed on Pardus Linux with LO 3.4
*** Bug 40963 has been marked as a duplicate of this bug. ***
*** Bug 38424 has been marked as a duplicate of this bug. ***
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
closing
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a86b99f368bdc5fb9f0461129808b31f5d2e3401&g=libreoffice-3-5 fdo#39510: fix yet more layout crashes in ~SwRootFrm: It will be available in LibreOffice 3.5.1.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-4": http://cgit.freedesktop.org/libreoffice/writer/commit/?id=a6d98bb23f5ced5cf4f03666099f4bcb1f7ab185&g=libreoffice-3-4 fdo#39510: fix yet more layout crashes in ~SwRootFrm: It will be available in LibreOffice 3.4.6.
*** Bug 46896 has been marked as a duplicate of this bug. ***