Bug 39510 - CRASH closing document with footnotes
Summary: CRASH closing document with footnotes
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.2 RC1
Hardware: x86 (IA32) All
: highest critical
Assignee: Björn Michaelsen
URL:
Whiteboard: target:3.5.1 target:3.4.6
Keywords: regression
: 38424 39447 39647 39861 39899 39925 40331 40963 46896 (view as bug list)
Depends on:
Blocks: mab3.4
  Show dependency treegraph
 
Reported: 2011-07-24 13:27 UTC by gerdl
Modified: 2013-08-07 09:17 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:


Attachments
open the file, change one letter and close the file - crash (20.58 KB, application/vnd.oasis.opendocument.text)
2011-07-24 13:27 UTC, gerdl
Details
Modified file without crash (19.22 KB, application/vnd.oasis.opendocument.text)
2011-07-25 13:31 UTC, manj_k
Details
patch for debugging the issue (2.39 KB, patch)
2011-07-31 06:50 UTC, Björn Michaelsen
Details
patch for debugging the issue (2.96 KB, patch)
2011-07-31 12:21 UTC, Björn Michaelsen
Details
structure of the layout at the beginning of destruction and at the time of crash (47.69 KB, text/plain)
2011-08-01 02:23 UTC, Björn Michaelsen
Details
Crashlog from Mac OS X 10.7 (71.95 KB, text/plain)
2011-08-16 05:55 UTC, Frantisek Erben
Details
bug not fixed for this file (25.61 KB, application/vnd.oasis.opendocument.text)
2011-09-12 23:48 UTC, Bertan Gündoğdu
Details
odt file with footnotes that crash (160.73 KB, application/vnd.oasis.opendocument.text)
2011-09-13 13:21 UTC, [REDACTED]
Details
The MacOS X 10.6.8 crashlog when closing the sample document from Astrix (62.27 KB, text/plain)
2011-09-19 01:40 UTC, Roman Eisele
Details
patch killing footnotes first (780 bytes, patch)
2011-09-22 09:18 UTC, Björn Michaelsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description gerdl 2011-07-24 13:27:06 UTC
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.
Comment 1 Petr Mladek 2011-07-25 06:07:49 UTC
I see the crash also with 3.4.1-rc3 on Linux. I checked the 64-bit build on SLED11-SP1-x86_64.
Comment 2 Michael Meeks 2011-07-25 07:34:39 UTC
can reproduce with -3-4-2 rc2 on Linux; needs some valgrinding of writer I think.
Comment 3 Michael Meeks 2011-07-25 08:56:21 UTC
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.
Comment 4 Michael Meeks 2011-07-25 08:58:12 UTC
Any thoughts Cedric ? :-)
Comment 5 manj_k 2011-07-25 13:31:20 UTC
Created attachment 49536 [details]
Modified file without crash
Comment 6 manj_k 2011-07-25 13:38:32 UTC
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.
Comment 7 Rainer Bielefeld Retired 2011-07-25 23:19:10 UTC
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
Comment 8 Rainer Bielefeld Retired 2011-07-30 00:00:51 UTC
*** Bug 39647 has been marked as a duplicate of this bug. ***
Comment 9 Rainer Bielefeld Retired 2011-07-30 01:00:47 UTC
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.
Comment 10 Rainer Bielefeld Retired 2011-07-30 02:07:40 UTC
I also saw the crash with a daily build  nearby "LibreOffice 3.4.1 - WIN7  Home
Premium (64bit) German UI [OOO340m1 (Build:101)]"
Comment 11 gleppert 2011-07-30 05:13:15 UTC
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.
Comment 12 Björn Michaelsen 2011-07-31 06:50:45 UTC
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.
Comment 13 Björn Michaelsen 2011-07-31 09:15:35 UTC
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.
Comment 14 Björn Michaelsen 2011-07-31 12:21:37 UTC
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).
Comment 15 Björn Michaelsen 2011-07-31 13:34:18 UTC
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?)
Comment 16 Petr Mladek 2011-08-01 01:40:23 UTC
(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.
Comment 17 Björn Michaelsen 2011-08-01 02:23:21 UTC
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 ...
Comment 18 André Schnabel 2011-08-02 05:41:38 UTC
*** Bug 39447 has been marked as a duplicate of this bug. ***
Comment 19 manj_k 2011-08-05 15:51:01 UTC
*** Bug 39861 has been marked as a duplicate of this bug. ***
Comment 20 m_a_riosv 2011-08-07 05:34:32 UTC
If can help, in the attachment if you up one level the first heading, then don't crash.
Comment 21 manj_k 2011-08-07 13:58:41 UTC
*** Bug 39899 has been marked as a duplicate of this bug. ***
Comment 22 manj_k 2011-08-08 06:54:47 UTC
*** Bug 39925 has been marked as a duplicate of this bug. ***
Comment 23 Rainer Bielefeld Retired 2011-08-15 04:15:29 UTC
*** Bug 40092 has been marked as a duplicate of this bug. ***
Comment 24 Frantisek Erben 2011-08-16 05:55:35 UTC
Created attachment 50269 [details]
Crashlog from Mac OS X 10.7
Comment 25 Frantisek Erben 2011-08-16 05:57:12 UTC
It can be reproduced on Mac OS X 10.7 in LO 3.4.2 Release. Crashlog added.
Comment 26 gleppert 2011-08-19 08:34:40 UTC
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.
Comment 27 kitchin 2011-08-21 05:48:38 UTC
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.
Comment 28 Hans Immel 2011-08-21 06:15:08 UTC
(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.
Comment 29 Cédric Bosdonnat 2011-08-22 09:06:32 UTC
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.
Comment 30 Cédric Bosdonnat 2011-08-22 11:28:37 UTC
(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?
Comment 31 Björn Michaelsen 2011-08-23 03:40:13 UTC
No objections against that patch. It is much saner than what we had before.
Comment 32 Caolán McNamara 2011-08-23 04:31:13 UTC
I don't know anything to the contrary to make me thing its a bad idea anyway :-)
Comment 34 vitriol 2011-08-23 22:20:37 UTC
*** Bug 40331 has been marked as a duplicate of this bug. ***
Comment 35 Cor Nouws 2011-08-24 00:19:54 UTC
so a big applause for diving into this and fixing it guys :-)
Comment 37 Jean-Baptiste Faure 2011-08-24 22:09:03 UTC
Fix confirmed in LibreOffice 3.4.3 rc2 (Ubuntu 10.04 x86_64).

Thanks again. JBF
Comment 39 Frantisek Erben 2011-08-28 14:45:41 UTC
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
Comment 40 krzysztof pijarski 2011-09-07 05:04:09 UTC
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
Comment 41 vitriol 2011-09-07 05:18:39 UTC
@krzysztof pijarski
Could you provide a sample document?
Comment 42 Bertan Gündoğdu 2011-09-12 23:48:58 UTC
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.
Comment 43 vitriol 2011-09-12 23:57:18 UTC
No crash on closing for me. LibO 3.4.3 under Win7 Italian 64 bit.
Comment 44 Hans Immel 2011-09-13 03:19:10 UTC
(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)
Comment 45 Rainer Bielefeld Retired 2011-09-13 03:33:40 UTC
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?
Comment 46 Jean-Baptiste Faure 2011-09-13 13:16:55 UTC
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
Comment 47 [REDACTED] 2011-09-13 13:21:48 UTC
Created attachment 51163 [details]
odt file with footnotes that crash
Comment 48 [REDACTED] 2011-09-13 13:28:55 UTC
(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.
Comment 49 Bertan Gündoğdu 2011-09-13 23:11:50 UTC
@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"
Comment 50 Rainer Bielefeld Retired 2011-09-13 23:54:45 UTC
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.
Comment 51 Roman Eisele 2011-09-19 01:36:21 UTC
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 ...
Comment 52 Roman Eisele 2011-09-19 01:40:38 UTC
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 ...
Comment 53 Fabian Tröster 2011-09-19 08:37:21 UTC
(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
Comment 54 [REDACTED] 2011-09-21 01:38:56 UTC
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.
Comment 55 Björn Michaelsen 2011-09-22 09:18:57 UTC
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.
Comment 57 Björn Michaelsen 2011-09-22 09:53:44 UTC
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
Comment 58 Roman Eisele 2011-09-23 05:07:37 UTC
(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?
Comment 60 Roman Eisele 2011-09-27 11:31:41 UTC
(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).
Comment 61 Bertan Gündoğdu 2011-09-27 22:52:18 UTC
Fix confirmed on Pardus Linux with LO 3.4
Comment 62 akouane 2011-11-09 05:50:04 UTC
*** Bug 40963 has been marked as a duplicate of this bug. ***
Comment 63 Björn Michaelsen 2011-11-14 11:42:06 UTC
*** Bug 38424 has been marked as a duplicate of this bug. ***
Comment 64 Björn Michaelsen 2011-12-23 13:22:29 UTC
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.
Comment 65 Björn Michaelsen 2011-12-24 04:27:20 UTC
closing
Comment 66 Not Assigned 2012-02-20 09:02:15 UTC
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.
Comment 67 Not Assigned 2012-02-20 11:50:52 UTC
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.
Comment 68 Miklos Vajna 2013-08-07 09:17:41 UTC
*** Bug 46896 has been marked as a duplicate of this bug. ***