Writer freezes when trying to open big doc files, bigger than 1 Mb.
Operative system: Ubuntu 11.10
When I was still using Ubuntu 11.04, the version of Libre Office bundled with it (I don't know the number), DID open such files.
Could you please attach the file you encountered the problem? Also remove private information before posting here. Thanks.
That would be a problem. I've got plenty of "files I encountered the problem". Problem is, everyone of them is actually a piece of "private information", typeset books. How can I do to help you?
[NOT REPRODUCIBLE] I've tested with Ubuntu 11.10 LibreOffice 3.4.3 and my own .doc file 1.28 MB and it works fine, no freeze. Maybe could you test by filling with some random content, for example from http://www.lipsum.com/ please?
Created attachment 52901 [details] With this my Writer freezes No way to reproduce the bug with Lorem Ipsum. This is one of the original files.
[REPRODUCIBLE] LibreOffice 3.4.3 on Windows 7. What I observed: 1. Opening the file from the start center causes the status bar loading with "importing document" (expected) 2. Step 1 takes about 1 minute 3. After status bar was fully-loaded, LibreOffice freezed for a few seconds, and the document didn't appear. Start center was appearing again like nothing happened, and can be clicked, not freeze. (not expected) 4. Try to create new document from start center, it worked fine, like steps 1-3 was not happened before. 5. But the problematic document was locked with the .~lock.2.doc# hidden file. Alessandro, how this file was created? Is it created by LibreOffice or Word or ...? and which version? on which OS? I'll test again on Ubuntu, if no one beats me :) Thanks very much. ---- P.S. I forgot to give credits to cheche on #libreoffice irc for following suggestion. Thanks cheche again :D (In reply to comment #5) > Maybe could you test by filling with some random content, for example from > http://www.lipsum.com/ please?
Oh, I forgot again to say that: In step 1, I dragged the file into LibreOffice 6. Closing LibreOffice (File > Exit) didn't delete the locking hidden file in step 5. 7. Open the file again with "Open" button on start center => crash! but opening by dragging => didn't crash 8. I've tested with Word 2007 on Windows 7 and the attached file opened well.
It was created in Windows XP with Word 2003.
On my system, it crashes both ways, direct opening and drag-and-drop.
[REPRODUCIBLE] LibreOffice 3.4.3 Ubuntu 11.10 File > Open the attached document in comment 6 and see LibreOffice crash. Also crash when drag-and-drop, both after it's fully loaded (seeing from status bar). Since it's a crash -> set severity to major Cedric, feel free to reassign to the list if you want more information, or if it isn't your area. Please set status to ASSIGNED when you accept this bug. Thanks.
NOT reproduced on master with 2.6.35.14-103.fc14.x86_64
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.
Checked with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce. There is a few secs freeze only before displaying the file. No crash.
Created attachment 68646 [details] bt on master On pc Debian x86-64 with master sources updated today (and a brand new LO profile), I had a crash. I attached bt. I also noticed this specific log: warn:legacy.osl:21382:1:/home/julien/compile-libreoffice/libo/sot/source/sdstor/stgdir.cxx:419: Trying to resize readonly stream by seeking, could be a wrong offset!
Created attachment 68648 [details] valgrind part I didn't succeed to have the whole trace of Valgrind (although I waited for at least 15 minutes) I retrieved an interesting part of Valgrind anyway.
Created attachment 68650 [details] 2 naive alternatives patches to avoid crash Following the part of Valgrind trace, I attached 2 naive alternatives patches. 1) I push_back the value in the vector, then sort it 2) I took example of sc/source/ui/dbgui/csvsplits.cxx, bool ScCsvSplits::Insert( sal_Int32 nPos ) function. Searching lower bound, test the value found, etc... I prefer 1) but it would be nice to do the sort once.
Created attachment 68651 [details] Some bts at random I retrieved some bt at random (after having applied patch1 from my previous comment). Just some seconds after the last bt, the doc was fully opened. Hope it helps.
Cedric: one for you? (sorry I had forgotten to put a core dev on cc)
(In reply to comment #18) > Created attachment 68651 [details] > Some bts at random > > I retrieved some bt at random (after having applied patch1 from my previous > comment). Just some seconds after the last bt, the doc was fully opened. > > Hope it helps. I confirm. On Ubuntu 12.10 with LibreOffice 3.6.2.2, everything works fine. The administrators can consider the matter as settled. Thanks everybody.
Created attachment 72890 [details] bt + console logs on master On pc Debian x86-64 with master sources updated yesterday (commit ac56d9373a66378a04048993ed5aec65cf39f149), I had a crash. I attached bt + console logs. Thinking there could be a link with the freezes, I preferred attaching it on this bug tracker. Now, I could create a new tracker if necessary.
Comment on attachment 68651 [details] Some bts at random Fix mimetype
I reproduced the same with 4.0 sources updated yesterday. Quite weirdly, I reproduced the same with 3.6 sources but had the crash only on gdb! On 3.6, I've got this specific log repeated a lot: warn:legacy.osl:8597:1:/home/julien/compile-libreoffice/libo_3_6/sw/source/core/txtnode/ndhints.cxx:339: HintsCheck: Portion inconsistency. This can be temporarily ok during undo operations Michael/Cedric: would one of you have some time to take a look?
Restricted my LibreOffice hacking area
To give an update, I can reproduce this with master sources updated today. Just wonder if we could replace the std::vector by std::set since it seems there can be lots of insert or remove and we have to keep the container sorted.
caolanm->julien: Could you give this another test with master. I loaded it, and it was pretty slow to load on a full dbgutil debugging writer, but it did load for me without a crash.
No problem for me to load this file with master updated yesterday evening (Version: 4.4.0.0.alpha0+ Build ID: 9bb04da4bb18342a107bb843d8054e178d97ae28) built at home under Ubuntu 14.04 x86-64 Same test without problem with Version: 4.2.7.0.0+ Build ID: a7f7b93299a9a7af8b243099f78f236172c4cb51 and Version: 4.3.3.0.0+ Build ID: 50eac342603ca08d808f53dc9a32bb9d1dfba372 Best regards. JBF
julien->caolanm: thank you for pinging, indeed with LO Debian package 4.3.1.2 and with master sources updated today, I don't reproduce this. With the Jean-Baptiste's confirmation too, let's put this one to RESOLVED/WFM.