| Summary: | FILEOPEN: hangs with 100% CPU usage on specific .doc file | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | mlennert |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | NEW --- | QA Contact: | Joel Madero <jmadero.dev> |
| Severity: | major | ||
| Priority: | medium | CC: | barta, fezhang, iamtester8, jbfaure, jeffdchang, jmadero.dev, LibreOffice, mst.fdo, sasha.libreoffice, serval2412, yfjiang |
| Version: | 3.3.2 release | ||
| Hardware: | Other | ||
| OS: | All | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=60390 https://bugs.freedesktop.org/show_bug.cgi?id=34050 https://bugs.freedesktop.org/show_bug.cgi?id=34268 |
||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
LibO frozen after loading the file
bts at random This is the file with 3/4 of its contents removed - still causes freeze minimal version containing just a header - crashes bt at random |
||
|
Description
mlennert
2011-07-06 08:37:02 UTC
Reproduced on LibreOffice 3.4 340m1(Build:12) for OpenSuse Linux. Cannot entirely confirm, but I cannot download the attachment successfully. CPU tries downloading, appears on the task bar, then fails. Successfully opened the document on Windows Vista. Document looks normal--French, some box borders and highlighted phrases. Do not know what can possibly cause the crash. [Reproducible] with sample and "LibreOffice Portable 3.3.3 - WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:301 Tag 3.3.3.1)]" Also [Reproducible] with "LibreOffice 3.4.4RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:402)]" [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 5d1a991-4cb1bac-ca7e6f5-9125509-ce71330)]" (111109) This problem seems to be different from other "Open document with formula crash" problems I saw, because here also OOo 3.1.1 crashes All versions hangf with max CPU load @Cédric: 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. Fixed in master by this commit: http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a22e664811e10ca58ec66ba8fd10b1a6185c178 because i have no idea what that layout stuff is doing, i have done a bit of regression testing here: ive tested ~2000 odt files from bugzillas, in ~120 of those the removed bPosChgd branch was taken, and out of these i can reliably get different layouts on these documents: - ooo110461-1.odt this looks really bad, the OpenOffice.org logos are not visible at all. [you may claim that that is a feature, and i will consider a fix that replaces them with LibreOffice logos :), but having them just disappear is bad] - ooo49987-1.odt the graphic on page 21 is moved [looks different but harmless] - ooo115839-1.odt the header graphics are moved [there is already another ugly frame on the first page before the fix] so i'll set this to REOPENED because i think this needs investigation and we may need a different fix... master writes this on console when attempt to open: warn:legacy.osl:24045:1:/home/s/libre-master/core/sot/source/sdstor/stgdir.cxx:415: Trying to resize readonly stream by seeking, could be a wrong offset! warn:legacy.osl:24045:1:/home/s/libre-master/core/sw/source/core/txtnode/ndhints.cxx:339: HintsCheck: Portion inconsistency. This can be temporarily ok during undo operations soffice.bin: /home/s/libre-master/core/sw/source/core/bastyp/index.cxx:237: virtual SwIndexReg::~SwIndexReg(): Assertion `!m_pFirst && !m_pLast' failed. warn:legacy.osl:24045:1:/home/s/libre-master/core/unotools/source/config/configitem.cxx:70: Exception from PutProperties: configmgr inappropriate property value warn:legacy.osl:24045:1:/home/s/libre-master/core/unotools/source/config/configitem.cxx:70: Exception from PutProperties: configmgr inappropriate property value then appears window where Libreoffice tells that it crashed don't know how bad the other assertions are, but this one is implemented with assert(3) and causes an abort: SwIndexReg::~SwIndexReg(): Assertion `!m_pFirst && !m_pLast' failed. it should be fixed on master and libreoffice-3-5 already and i can't reproduce it, can you check that you have the following master commit and pull/rebuild if not: 6c3e8f9d19a0392a817c1b5692421ed0972a3b7e Sorry that my master is not very contemporary. Used version is 97fdf02-9eed775-f061262. And versions 3.3.4 and 3.5.0 on Fedora 64 bit hangs when attempt to open file. 3.6.0 master fdb9d72-9eed775-f06126 not hangs, outputs on console this: warn:legacy.osl:4013:1:/usr/src/libre-master/core/sot/source/sdstor/stgdir.cxx:415: Trying to resize readonly stream by seeking, could be a wrong offset! warn:legacy.osl:4013:1:/usr/src/libre-master/core/sw/source/core/txtnode/ndhints.cxx:339: HintsCheck: Portion inconsistency. This can be temporarily ok during undo operations warn:editeng.items:4013:1:/usr/src/libre-master/core/editeng/source/items/paraitem.cxx:676: SvxOrphansItem::GetPresentation(): unknown SfxItemPresentation warn:editeng.items:4013:1:/usr/src/libre-master/core/editeng/source/items/paraitem.cxx:604: SvxWidowsItem::GetPresentation(): unknown SfxItemPresentation warn:vcl:4013:1:/usr/src/libre-master/core/vcl/source/control/button.cxx:1836: No handler installed for CancelButton And when save as odt file, http://odf-validator.rhcloud.com/ outputs this: anformulairechairessud2011.odt/styles.xml[243,91]: Error: attribute "text:start-value" has a bad value: "0" does not satisfy the "positiveInteger" type Created attachment 58970 [details]
LibO frozen after loading the file
issue confirmed on 3.5.1 using Vista 64bit.
1- start LibO
2- load file from "open button"
3- LibO is frozen and never opens the file
see screenshot
Again [Reproducible] with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit), But (@tommy27): It's fixed in MASTER 2012-02-08, so a fix can't be in 3.5.2.2 (also see target information in Whiteboard) @Sasha: The problems you observed with your "more contemporary" Master might be related, So I urgently recommend to open a new bug for that issue (with a reference to this Bug) and close this one. Can you please always add the push-date or similar with the Version information? It's impossible for me to see a date version in the Build ID. Only for the sake of completeness: Parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 3ddf85d-6299bf6-879ce3]" (tinderbox: Win-x86@6-fast pull time 2012-03-30 00:06:13) opens the sample document without problems. Sorry for my experiments with Master building was not useful. Separate bugreport about validation was this: Bug 45895 Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=960d72c0d721b08dcf331c8caf51ea4a99b501ef Revert "fdo#39006: Fixed layout loop" problems in comment #4 need investigation => reverted for now, reopen Tested on Debian SID failed for me too... tested LO 3.5.4 Still [Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 25608fb]" (tinderbox: 2008R2@20, pull time 2012-07-14 00:31:17), HANG when Try to open from Start Center file menu Created attachment 71598 [details]
bts at random
On pc Debian x86-64 with master sources updated today, I reproduced the problem.
I had no specific logs but I retrieved 3 bts at random.
Hope it may help.
Comment on attachment 71598 [details]
bts at random
fix mimetype
Still [Reproducible] with Version 4.0.0.0.beta1+ (Build ID: 546faa79bf3b1e4b222f182d43a9839106a398d) tested on Vista 64bit This one seems to be really tricky, I'll nominate it as possible HardHack on <https://wiki.documentfoundation.org/HardHacks> (what ever that might help ...) Verified: Version 4.1.0.0.alpha0+ (Build ID: 80cbc04c2cbe25ebdfe2f22bb2e5ba62728e963) Bodhi Linux +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I tend to disagree that this is a MAB, again because it affects a single document and cannot be reproduced independent of that single document. For now I will move it to 3.6 MAB (3.5 is at EOL so no more work is being done on it). We're trying to close the 3.5 most annoying meta bug. If another QA member agrees with me, we should remove this from MAB list. @Reporter - removing from MAB does not mean that your bug will go unnoticed or forgotten. Just in general MAB should affect a lot of users and this doesn't seem to be like that as it's a single document. I can reproduce this in LO 3.6.5.2/Fedora, LO hangs opening file. still reproducible with LibO 4.0.2 on Windows Vista 64bit On pc Debian x86-64 with master sources updated today, I still reproduce the hanging too :-( Comment on attachment 58970 [details]
LibO frozen after loading the file
still reproducible on LibO 4.1.0.4
Removing from MAB list - as mentioned before - a single document showing the problem and one user (lots of QA and devs confirming) being affected. Again this does not mean it's not being investigated, it only means that MAB should be bugs that affect many many users - this one does not from what I can tell. Thanks mlennert and all others for testing and continuing to try to solve this one. Some additional info: Confirmed with master 2013-08-16_00.24.23 LibO dev 4.1 MS Office 2010 Professional Plus 32bit opens the file without problems. But the following might be interesting: The issue is reproducible with the current Apache OpenOffice 4.0.0 as well, the symptoms are exactly the same. My machine: Windows 7 SP1, 64bit @Hans have you tried removing pages or elements of that .doc file in order to reduce it to a minimal version that still freezes LibO? the less stuff remains the higher chances to identify what causes the issue. @tommy: so far I was able to delete all contents of pages 1,2 and 4 while leaving page 3 unchanged - this will still freeze LibO. Can anyone with access to MS Office confirm this? Otherwise I could upload the modified version of the file later. Furthermore the freeze doesn't occur when converting the file from .doc to .docx using MS Office and then opening the resulting .docx file in LibO. So the issue is most likely to be found somewhere in the .doc filter and caused by some content on page 3 of the document. please, upload here the minimal version test case. Created attachment 85261 [details]
This is the file with 3/4 of its contents removed - still causes freeze
There you go, I attached the modified file. As mentioned above I removed the contents of pages 1, 2 and 4.
I left page 3 unmodified; the resulting file still cannot be opened by LibO and causes it to freeze.
well done Hans. that will make easier for the devs to debug it. I confirm it still freezes 4.1.1 and 4.2 master build Sept 3. what about going deeper? you already reduced the document down to 1 page... try removing some more elements inside it (text, images, table, whatever...) till the bug can be reproduced. Created attachment 85378 [details]
minimal version containing just a header - crashes
Tommy27: I went the whole way now, it seems like we have it:
I attached a minimal version of the document, consisting of just two blank pages and a header; it causes LibO to freeze. If you remove the header it won't cause any freeze.
Could you please confirm this?
Created attachment 85382 [details]
bt at random
On pc Debian x86-64 with master sources updated today, I still reproduce this.
I attached a bt at random.
Forgot to say I used the minimal version containing just a header! (In reply to comment #34) > Created attachment 85378 [details] > minimal version containing just a header - crashes > > Tommy27: I went the whole way now, it seems like we have it: > > I attached a minimal version of the document, consisting of just two blank > pages and a header; it causes LibO to freeze. > Could you please confirm this? yes, still a crasher in 4.1.1.2 Still the same problem with master sources updated yesterday. Restricted my LibreOffice hacking area Problem persists in LibO 4.2.0 RC3. Master is still affected: Version: 4.3.0.0.alpha1+ Build ID: cd11bc699ac50af4f560ed5f2e5e7903de0898b8 TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-05-20_08:02:54 Freeze while trying to open. 4.3.0-release still affected by the issue. Confirmed too with master sources updated today. Current master is still affected, can be reproduced with: Version: 4.4.0.0.alpha0+ Build ID: 9177329a425cf70b515d1f266132838894fe54c6 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-06_01:02:02 On pc Debian x86-64 with master sources updated today, I confirm hanging.
448 sal_uInt16 GetType() const { return 0x1 << mnType; }
(gdb) bt
#0 0x00002aaac6c6b1b3 in SwFrm::GetType (this=0x3071a00) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/inc/frame.hxx:448
#1 0x00002aaac6c6b274 in SwFrm::IsCntntFrm (this=0x3071a00) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/inc/frame.hxx:1207
#2 0x00002aaac711d483 in lcl_NextFrm (pFrm=0x3071a00) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/findfrm.cxx:627
#3 0x00002aaac711d7a5 in SwFrm::_FindNext (this=0x3070d70) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/findfrm.cxx:698
#4 0x00002aaac711e5f9 in SwFrm::ImplInvalidateNextPos (this=0x3070d70, bNoFtn=false) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/findfrm.cxx:1094
#5 0x00002aaac714b14a in SwFrm::InvalidateNextPos (this=0x3070d70, bNoFtn=false) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/inc/frame.hxx:1028
#6 0x00002aaac7149160 in lcl_CheckFlowBack (pFrm=0x3070d70, rRect=SwRect = {...}) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:2817
#7 0x00002aaac71490cb in lcl_CheckFlowBack (pFrm=0x3070c00, rRect=SwRect = {...}) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:2810
#8 0x00002aaac71490cb in lcl_CheckFlowBack (pFrm=0x30707b0, rRect=SwRect = {...}) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:2810
#9 0x00002aaac714950c in Notify_Background (pObj=0x3071170, pPage=0x30707b0, rRect=SwRect = {...}, eHint=PREP_FLY_LEAVE, bInva=true)
at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:2897
#10 0x00002aaac71397bf in SwFlyFreeFrm::NotifyBackground (this=0x3070ef0, pPageFrm=0x30707b0, rRect=SwRect = {...}, eHint=PREP_FLY_LEAVE)
at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/flylay.cxx:94
#11 0x00002aaac7148a08 in Notify (pFly=0x3070ef0, pOld=0x30707b0, rOld=SwRect = {...}, pOldPrt=0x7ffffffed3e8)
at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:2737
#12 0x00002aaac7141bde in SwFlyNotify::~SwFlyNotify (this=0x7ffffffed3c0, __in_chrg=<optimized out>)
at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/frmtool.cxx:658
#13 0x00002aaac713a217 in SwFlyFreeFrm::MakeAll (this=0x3070ef0) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/flylay.cxx:214
#14 0x00002aaac7133e97 in SwFlyAtCntFrm::MakeAll (this=0x3070ef0) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/flycnt.cxx:374
#15 0x00002aaac710c1f9 in SwFrm::PrepareMake (this=0x3070ef0) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/calcmove.cxx:340
#16 0x00002aaac6f2e85e in SwFrm::Calc (this=0x3070ef0) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/inc/frame.hxx:1034
#17 0x00002aaac7131b12 in SwFlyFrm::Calc (this=0x3070ef0) at /home/julien/compile-libreoffice/libreoffice/sw/source/core/layout/fly.cxx:2633
#18 0x00002aaac717ba6d in SwObjectFormatter::_FormatLayout (this=0x3073490, _rLayoutFrm=...)
I read about something wrong on layout management but don't know more about this.
I also think that more than the 2 fdo put in see also could be kindda dup or at least related. But I should search on bugtracker to confirm it (or not!).
Michael: any thoughts/related urls about this?
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.