Apache OpenOffice (AOO) Bugzilla – Issue 19457
Writer loops on load with this file
Last modified: 2013-08-07 14:43:45 UTC
using OOo on Win2k SP4 Tested on 1.0.3, 1.1Beta2, 1.1RC3, 1.1RC4 Progressbar 100% ok gray background with a static cursor in middle of screen Hard disk heavily stressed Waited for 6 minutes to display Have to shut OOo down (no crash report) Laurent
Created attachment 9207 [details] The file ...
adding Sophie as requested
I confirm this issue. On GNU/Linux, it was killed by OOM killer, because of: 5668 pavel 25 0 885m 490m 924 R 51.3 79.1 4:37.20 soffice.bin There seems to be a memleak somewhere... I run it in gdb and stopped it several times: Program received signal SIGINT, Interrupt. 0x413ef5e7 in poll () from /lib/libc.so.6 (gdb) where #0 0x413ef5e7 in poll () from /lib/libc.so.6 #1 0x44e63539 in typeinfo for com::sun::star::sdbc::SQLException () from /tmp/OpenOffice.org1.1.0/program/libdtransX11645li.so #2 0x44e636ae in typeinfo for com::sun::star::sdbc::SQLException () from /tmp/OpenOffice.org1.1.0/program/libdtransX11645li.so #3 0x40bd867e in osl_getTextEncodingFromLocale () from /tmp/OpenOffice.org1.1.0/program/libsal.so.3 #4 0x41149c60 in pthread_start_thread () from /lib/libpthread.so.0 #5 0x41149cdf in pthread_start_thread_event () from /lib/libpthread.so.0 (gdb)
added ooqa and crash keywords? Is this crahs only related to this specific document or can you create a new document, that would crash the same way? If only for this document, this is "only" prio 3 (crash in very special circumstances)
This file has been submitted to OOOconv and NO i can't reproduce myself this crash with a new document so P3 ? Laurent
I can reproduce it at 1.1 Rc4 Win Xp It is only small file, but it cannot open for long time. so I close the OOo Yes, It is a bugs
set at least to 1.1.1
reassigned to mru set Prio to P3 set Target to OOo1.1.1
FME->LaurentGodard: Looks like the file has been a *.doc file in its former life. I had a look into the content.xml file: <style:style style:name="P83" style:family="paragraph" style:parent-style-name="Standard" style:list-style-name="WW8Num12"><style:properties fo:margin-left="115.57cm" fo:margin-right="0cm" .... Hmmm, left margin of 115.57cm causes the text formatting to choke if the page width is only 21.59cm. Could you please send us the original word file, so that our filter expert can have a look at it?
Hi, This file has been "posted" on OOOConv (http://oooconv.free.fr/engine/oooconv.php) leading it to crash I don't have the original file either the person who submitted it It seems to have been posted from Norway (server log analysis) I'm sorry Laurent
I can reproduce this on a debug build of 1.1rc4. I used the valgrind-derivative tool "Massif" (see http://www.cl.cam.ac.uk/~njn25/valgrind.html) This gives a graphical view of heap usage over time. I let it run until my box was almost out of swap space. I assume this leak happens because there is some infinite loop which allocates memory. And so Massif shows that just 3 stack backtraces allocate 67% of all the space in the leak, and the top 5 backtraces allocate 91.9% of the space in the leak. This should give you a pretty good start in looking for the allocation loop. These 5 allocation points are listed below. Julian Seward Context accounted for 33.3% of measured spacetime 0x40D7F7D3: rtl_allocateMemory (alloc.c:1302) 0x808DA3E: allocate(unsigned, (anonymous namespace)::AllocatorTraits const&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:183) 0x808DB60: operator new(unsigned) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:106) 0x40262AC5: Font::MakeUnique() (/home/oobuild/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/font.cxx:151) 0x402630D9: Font::SetFamily(FontFamily) (/home/oobuild/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/font.cxx:315) Context accounted for 16.6% of measured spacetime 0x40D7F7D3: rtl_allocateMemory (alloc.c:1302) 0x808DA3E: allocate(unsigned, (anonymous namespace)::AllocatorTraits const&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:183) 0x808DB60: operator new(unsigned) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:106) 0x40262AC5: Font::MakeUnique() (/home/oobuild/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/font.cxx:151) 0x4026318C: Font::SetCJKContextLanguage(unsigned short) (/home/oobuild/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/font.cxx:345) Context accounted for 27.0% of measured spacetime 0x40D7F7D3: rtl_allocateMemory (alloc.c:1302) 0x808DA3E: allocate(unsigned, (anonymous namespace)::AllocatorTraits const&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:183) 0x808DB60: operator new(unsigned) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:106) 0x5726D7A5: SwTxtFormatter::NewNumberPortion(SwTxtFormatInfo&) const (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/txtfld.cxx:421) 0x5724FA4A: SwTxtFormatter::WhichFirstPortion(SwTxtFormatInfo&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/itrform2.cxx:1133) Context accounted for 7.9% of measured spacetime 0x40D7F7D3: rtl_allocateMemory (alloc.c:1302) 0x808DA3E: allocate(unsigned, (anonymous namespace)::AllocatorTraits const&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:183) 0x808DB60: operator new(unsigned) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:106) 0x5726D960: SwTxtFormatter::NewNumberPortion(SwTxtFormatInfo&) const (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/portxt.hxx:108) 0x5724FA4A: SwTxtFormatter::WhichFirstPortion(SwTxtFormatInfo&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/itrform2.cxx:1133) 0x5724FCF8: SwTxtFormatter::NewPortion(SwTxtFormatInfo&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/itrform2.cxx:1246) Context accounted for 7.1% of measured spacetime 0x40D7F7D3: rtl_allocateMemory (alloc.c:1302) 0x808DA3E: allocate(unsigned, (anonymous namespace)::AllocatorTraits const&) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:183) 0x808DB60: operator new(unsigned) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sal/cpprt/operators_new_delete.cxx:106) 0x40B140C9: FixedMemPool::Alloc() (/home/oobuild/openoffice/build/OOO_1_1_RC4/tools/source/memtools/mempool.cxx:98) 0x57239526: SwTxtFrm::_Format(SwTxtFormatter&, SwTxtFormatInfo&, unsigned char) (porlay.hxx:247) 0x57239E2C: SwTxtFrm::_Format(SwParaPortion*) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/frmform.cxx:1849) 0x5723A6E2: SwTxtFrm::Format(SwBorderAttrs const*) (/home/oobuild/openoffice/build/OOO_1_1_RC4/sw/source/core/text/frmform.cxx:2051)
Created attachment 9523 [details] More detailed allocation stacks from which top 5 were harvested
Created attachment 9524 [details] Pretty but useless PostScript picture pertaining to profiling run
MRU->ES: .sxw file loops, please investigate.
As long as we cannot reproduce the import problem (using the original bug doc) we can't fix anything. It's too bad but I have to close this issue. Fo who it may concern, I attach a recovered version of the sxw file.
Created attachment 9595 [details] Recovered version of the sxw file
Worksforme
closed
Did you fixed the memleak itself? If not, could please fix it before closing this document? By marking it WORKSFORME, daoes it mean that OOo does nt memleak for you? I do not believe so.
Good point! ES->FME: Actually there are 2 bugs: - Wrong import/export produces "non-sense" value -> we can't reproduce this becaude of a lack of original file (please ask CMC anyway if he has an idea how this may hapen) - Those value lead to a loop: which is not acceptable. If the file can't be loaded OOo should display an error message (wrong format or so) but not loop.
add my self to cc. Error message is better than crash/looping. but I hope we can fix it totally in 2.0 Thanks
FME: Ok, if any of these margin values (left margin, right margin, first line indent) > USHRT_MAX, I take the default values. Fixed in sw/source/core/text/itrform2.cxx rev. 1.77.184.1 (cws os21)
FME: Fix has been reviewed by AMA.
Fixed in cws os21 on so-cwsserv02, wntmsci8 and unxlngi5.pro
Checked fix in CWS os21. The problem was insisted by a faulty WinWord import (see issue 19323), which also will be fixed for OO 1.1.1.
Verified. Fix will be included in OO 1.1.1.
No crash anymore with srx645m27. Closed.