Steps how to reproduce with Server Installation of "LibreOffice 3.6.0.1 rc German UI/Locale [Build-ID: 73f9fb6] on German WIN7 Home Premium (64bit): 0. Download sample document attachment 61925 [details] of Bug 48932 1. Launch LibO 3.6 > Start center appears 2. Menu 'File -> Open -> Sample document' 3. Menu 'Tools -> Word count' As expected word count message box appears Bug: Crash In other attempts Crash already happens when I click "Tools" or do other smaller actions. With a little luck LigO will only hang for some seconds or minutes, but very very often I see a crash. Same with 3.5.5.3, other 3.5 not tested. 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) Works fine with "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit), so REGRESSION This one might be a DUP of Bug 52080, but currently that one is for Linux 7 3.6.0.1 rc, so I can't see whether we are talking about the same problem. Related bugs might be Bug 48932, Bug 48011 Of course 7000 pages are not a standard application, but we had this working with 3.4.5, so 3.5 MAB
Also unusable: "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) also crashes simply gambling in the menus.
(In reply to comment #0) > Of course 7000 pages are not a standard application, but we had this working > with 3.4.5 Should we add the 'regression' keyword then?
Created attachment 64227 [details] MacOS X log created when I had to force-quit LibO 3.5.5 On MacOS X 10.6.8 (Intel), I can't reproduce the crash for now, neither with LibO 3.5.5.3 nor with 3.6.0.1, both with German langpack installed ... Especially the word count dialog works for me without any problems, opening it is even the fastest (!) thing I can do with this document. So the crash may be specific to LibO for Windows, and someone else should confirm this. But I can confirm that even selection a single word or moving the cursor is incredible slow with this document; it freezes for seconds or even minutes. After some selecting and de-selecting, I tried (for the 3rd time or so) to select something from the format menu, and this time LibO *froze* forever; I had to force-quit it. Attached you find the log file created by MacOS X for this quit (however, I don't think that it will help much). But this freeze confirms that there is really something wrong with handling such big documents, not only on Windows, but also on MacOS.
On pc Debian x86-64, with master sources updated today, no crash. It's quite long to load but I can use Word count for example.
@Julien: Thanks for testing on Debian! So we can conclude: comment #3 and comment #4 together show that the *crash* is Windows-only. (But some other problems with the handling of such big documents are cross-platform, see comment #3.)
I would suspect the there isn't one problem with it on Windows and another with it on Linux but that the crash versus the extreme slowness is due to how the operating systems handle the problem. With Linux it would seem that the processor is bogged down until it gets through whatever is happening but Windows tries to act like everything is OK until it just can't anymore. I also suspect that the problem may be due to the new way of dealing with headers & footers since that was such a major change between version 3.4.6 & 3.5. I was doing some experimentation with different size files I would guess that there is some loop that is being processed for the whole document whenever something is selected or changed. It seems that as the file gets progressively larger the processing keeps getting slower in proportion to the size. It may also have something to do with the complexity of the document. I have documents that have far less pages but have many paragraph and character style changes along with many footnotes which do not work with version 3.5 or greater. I hope this gets fixed soon because I am unable to upgrade until it does or will need to go to OpenOffice 4 whenever that is released.
I tried this file on Ubuntu 11.10 x86_64 with LO 3.6.1.0+ (Build ID: cc304dc) No problem to load the file and scroll down. Word count works. But LO freeze with 100% CPU if I scroll down and try to select one or several words. Best regards. JBF
Since it seems like this is confirmed I am going going to mark this bug as NEW to get it out of UNCONFIRMED status. Should we open separate bugs for Windows/Mac/Linux and then make them dependent on each other since there is different behavior but probably all are caused by the same issue?
It's already opened as bug 52080 for Linux.
(In reply to comment #9) > It's already opened as bug 52080 for Linux. Both bugs are probably related, but bug 52080 is about "Large files becom[ing] unresponsive", and the present bug report is especially about the "CRASH on any action" for a particular big .odt file. This crash is -- an even more severe issue (crash!) -- but specific to Windows -- and specific to a particular document. Therefore it is reasonable to have special bug reports for both issues.
I reproduce bug with 3.6.0 under Win7x64 I don't reproduce it anymore with 4.3.2 RESOLVED WORKSFORME