Trying to open the .doc file available at http://www.cud.be/images/stories/docs/AN/anformulairechairessud2011.doc makes LibreOffice hang both on Debian Squeeze and on Windows 7.
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?
Tested with LibO 5.0 RC1 64bit (5.0.0.1 (x64)) on Win 7, 64bit: same result, causes LibO to freeze permanently.
Fixed in master - tested with LibO Dev 5.1 alpha (x64) / master 2015-10-19_21:22:52 on Windows 7 64. All versions of the document attached here can be opened and viewed normally, without any freeze. Can anyone else confirm this? If yes, then I think this can be changed to RESOLVED.
On pc Debian x86-64 with master sources updated today, still lots of warn:sw:4048:1:sw/source/core/layout/hffrm.cxx:274: SwHeadFootFrm::FormatSize: loop detection triggered in both cases (above all with doc link provived in initial description) but indeed it opens. Now I don't know if it can be considered as WFM. Perhaps we should change the title to indicate a perf pb and let this bugtracker opened?
Migrating Whiteboard tags to Keywords: (perf)
I close as WFM per Comment 47 and my test. Opens from LO 5.0.4. Perf and layout should be another issue.