soffice.bin crashed with SIGSEGV in SwTxtFtn::DelFrms()

Bug #854626 reported by Björn Michaelsen on 2011-09-20
42
This bug affects 4 people
Affects Status Importance Assigned to Milestone
LibreOffice
Fix Released
Critical
libreoffice (Ubuntu)
High
Björn Michaelsen

Bug Description

Open, then close the file at:
https://bugs.freedesktop.org/attachment.cgi?id=51163

ProblemType: Crash
DistroRelease: Ubuntu 11.10
Package: libreoffice-core 1:3.4.3-1ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu1
Architecture: amd64
CrashCounter: 1
Date: Tue Sep 20 12:53:02 2011
Disassembly: => 0x31d88: Cannot access memory at address 0x31d88
ExecutablePath: /usr/lib/libreoffice/program/soffice.bin
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
ProcCmdline: /usr/lib/libreoffice/program/soffice.bin --writer /tmp/Finale\ Chapter\ 2\ draft\ 1.odt --splash-pipe=7
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SegvAnalysis:
 Segfault happened at: 0x31d88: Cannot access memory at address 0x31d88
 PC (0x00031d88) not located in a known VMA region (needed executable region)!
SegvReason: executing unknown VMA
Signal: 11
SourcePackage: libreoffice
StacktraceTop:
 ?? ()
 SwTxtFtn::DelFrms(SwFrm const*) () from /usr/lib/libreoffice/program/../basis-link/program/libswlx.so
 ?? () from /usr/lib/libreoffice/program/../basis-link/program/libswlx.so
 ?? () from /usr/lib/libreoffice/program/../basis-link/program/libswlx.so
 ?? () from /usr/lib/libreoffice/program/../basis-link/program/libswlx.so
Title: soffice.bin crashed with SIGSEGV in SwTxtFtn::DelFrms()
UpgradeStatus: Upgraded to oneiric on 2011-06-28 (83 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

Created attachment 49478
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.

Download full text (7.1 KiB)

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/libreoff...

Read more...

Any thoughts Cedric ? :-)

Created attachment 49536
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
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
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
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
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 :-)

*** Bug 40331 has been marked as a duplicate of this bug. ***

so a big applause for diving into this and fixing it guys :-)

Fix confirmed in LibreOffice 3.4.3 rc2 (Ubuntu 10.04 x86_64).

Thanks again. JBF

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
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
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
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

visibility: private → public
Changed in df-libreoffice:
importance: Unknown → Critical
status: Unknown → In Progress

StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()

Changed in libreoffice (Ubuntu):
status: New → Invalid

Thank you for your report!

However, processing it in order to get sufficient information for the
developers failed (it does not generate an useful symbolic stack trace). This
might be caused by some outdated packages which were installed on your system
at the time of the report:

outdated debug symbol package for libavahi-common3: package version 0.6.30-4ubuntu1 dbgsym version 0.6.30-0ubuntu2
outdated debug symbol package for libtiff4: package version 3.9.5-1ubuntu1 dbgsym version 3.9.4-5ubuntu6
outdated debug symbol package for libk5crypto3: package version 1.9.1+dfsg-1ubuntu1 dbgsym version 1.8.3+dfsg-5ubuntu2.1
outdated debug symbol package for libavahi-client3: package version 0.6.30-4ubuntu1 dbgsym version 0.6.30-0ubuntu2
outdated debug symbol package for passwd: package version 1:4.1.4.2+svn3283-3ubuntu2 dbgsym version 1:4.1.4.2+svn3283-3ubuntu1
outdated debug symbol package for libkrb5-3: package version 1.9.1+dfsg-1ubuntu1 dbgsym version 1.8.3+dfsg-5ubuntu2.1
outdated debug symbol package for libgstreamer-plugins-base0.10-0: package version 0.10.35-1 dbgsym version 0.10.32-1ubuntu5
outdated debug symbol package for libdatrie1: package version 0.2.4-3 dbgsym version 0.2.4-1
outdated debug symbol package for librdf0: package version 1.0.13-3 dbgsym version 1.0.12-1
outdated debug symbol package for libgssapi-krb5-2: package version 1.9.1+dfsg-1ubuntu1 dbgsym version 1.8.3+dfsg-5ubuntu2.1
outdated debug symbol package for libxslt1.1: package version 1.1.26-7 dbgsym version 1.1.26-6build1
outdated debug symbol package for libkrb5support0: package version 1.9.1+dfsg-1ubuntu1 dbgsym version 1.8.3+dfsg-5ubuntu2.1
outdated debug symbol package for libthai0: package version 0.1.15-2 dbgsym version 0.1.14-2ubuntu1

Please upgrade your system to the latest package versions. If you still
encounter the crash, please file a new report.

Thank you for your understanding, and sorry for the inconvenience!

tags: removed: need-amd64-retrace

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
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.

(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?

Changed in df-libreoffice:
status: In Progress → Fix Released
Changed in libreoffice (Ubuntu):
assignee: nobody → Björn Michaelsen (bjoern-michaelsen)
milestone: none → ubuntu-11.10
Changed in libreoffice (Ubuntu):
status: Invalid → In Progress
importance: Undecided → High
Changed in libreoffice (Ubuntu):
status: In Progress → Fix Committed

(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

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libreoffice - 1:3.4.3-3ubuntu1

---------------
libreoffice (1:3.4.3-3ubuntu1) oneiric; urgency=low

  * merge from debian 3.4.3-3
  * also merge Build-Conflicts from debian
  * still use internal freejreport for oneiric release

libreoffice (1:3.4.3-3) unstable; urgency=low

  * debian/patches/jdk-1.7.0-vendorname.diff: backport from master; allow
    "Oracle Corporation" JDK >= 1.7.0 (closes: #642425)
  * debian/patches/s390x.diff: add patch from aurel32 to fix build on s390x
    (closes: #642951)

  * debian/rules:
    - build against "normal" pentaho libraries again, in new upstream versions
      (closes: #641594)
    - build with -g on {,kfreebsd}{i386,amd64} (similar to linux-2.6's -dbgs)
      as policy says. Compress with xz
    - allow openjdk 7; build against it on ia64 even when the rest is at 6
    - stop building -gcj on all openjdk-archs, keep it on gcj-using archs
    - build with gcc 4.6 again, add build-conflicts on g++ 4.6.1-10 and -11

  * merge from ubuntu-oneiric-3.4:
    - fixing crash on closing document with footnotes (LP: #854626)
    - fixing crash on screen resolution change (LP: #852819)

libreoffice (1:3.4.3-2) unstable; urgency=medium

  [ Rene Engelhard ]
  * debian/patches/no-deprecated-options-in-qstart-wrappers.diff: use --writer
    instead of -writer (closes: #638868)
  * debian/patches/fix-sample-icc-1.3.2-patch.diff: backport from master:
    re-enable patch hunk to fix PDF A/1-a export on 64bit archs, thanks lmamane
    for the patch (closes: #633480)
  * debian/patches/update-sdbc-postgresql.diff: update SDBC PostgreSQL
    driver to Lionels new LibreOffice version.
  * debian/patches/handle-NULL-display-gracefully.diff: backport from
    libreoffice-3-4

  * debian/control.in:
    - remove obsolete Pre-Depends on debconf in ure
    - add Breaks: on incompatible -cores on -common (basis-link symlink)
      (closes: #641357)
  * debian/control.postgresql.in: add (>= 8,4) to postgresql suggests to make
    more visible that we need >= 8.4 of PostgreSQL. Update Homepage for new
    LibreOffice location
  * debian/control.reportdesign.in: make -report-builder depend on
    -report-builder-bin (>= ${base-version}) (closes: #640900)
  * debian/rules:
    - re-enable -sdbc-postgresql
    - fix adding PYTHONPATH to unopkg (closes: #625878)
    - temporarily build with gcc 4.5 as gcc 4.6.1-10 breaks the vcl build
  * debian/libreoffice-common.links, debian/rules:
    - fix mimetype icon links for hicolor (closes: #641860)

  [ Lionel Elie Mamane ]
  * debian/rules: we need translate-toolkit (>= 1.9.0)
 -- Bjoern Michaelsen <email address hidden> Thu, 29 Sep 2011 15:14:29 +0200

Changed in libreoffice (Ubuntu):
status: Fix Committed → Fix Released

*** 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.

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. ***

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.