Description: Writer has many, many problems with large (>1.75Mb) files, including crashing. Steps to Reproduce: 1. Open file. 2. Navigate to near the end of the document & save it. 3. Open the file again so the file is opened near the end of the file. 4. Window > New Window. 5. In the new window, click on the vertical slider bar. (If it doesn't crash, repeat, pressing Ctrl-Home first). Actual Results: crashes Expected Results: To go to the top of the document. Reproducible: Always User Profile Reset: No Additional Info: All versions of Windows 10, on 32- & 64-bit installations. File size 2000 pages & larger, 2Mb or larger. No images. Just text. ----------------- Confirmed Writer versions: 7.1 thru latest release of 7.2 ----------------- This is an inherited problem from Open Office. It's a design problem in that shortly after a file is opened the software does something (scans the entire document?). It is not apparent on small files because it happens so quickly. A large file makes it extremely apparent. There are many other problems this creates. Even when it doesn't crash, the number of pages in the file is oftentimes incorrect until the 'scanning' stops. When halfway down in the document or lower, the pages keep jumping around, preventing moving to the desired location. It also crashes in other scenarios, but here's the easiest procedure I've found to reproduce the crash. I could go on, but you get the point. Until well after the 'scanning' is complete, the file isn't usable.
Further actions noted: * LibreOffice & OpenOffice aren't scanning the file, but reading it into memory? * All other open LibreOffice files (other Writer files, Calc files, Draw files, everything) are frozen while the scanning is taking place, so it shuts everything down. * After the scanning appears to be completed, there's still something happening because response time when typing at times is really slow - it's not my computer being slow either. * Time required to save a file is half of what it takes in OpenOffice though. OpenOffice takes as long as the scan, so you've improved something since starting with OpenOffice code. Great move!
Please attach some sample document, which does crash for you. I can be dependent on layout, even if it's plain text. So it's hard to reproduce from scratch you might sanitize the file https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission But well not sure how long it would take.. it's kind of slow to do :-( .* LibreOffice & OpenOffice aren't scanning the file, but reading it into memory? It's rendering the text, positioning footnotes, spell checking in the background.. but it takes far longer for larger files.. * Writer files, Calc files, Draw files, everything) are frozen while the scanning is taking place Well this a software architecture issue. It's not a nice thing though
What you call scanning could be repagination. There were other bugs on that.
Created attachment 177881 [details] large test file
Test File attached. Telesto: Thank you for the information on how to sanitize a file. As to be expected, both procedures crashed, freezing the application. Instead, I replaced some of the characters with an "X", which should be sufficient. Your comment that "LibreOffice & OpenOffice aren't scanning the file, but reading it into memory? It's rendering the text, positioning footnotes, spell checking in the background.. but it takes far longer for larger files.." is exactly what I was attempting to describe. Thank you. Timur: I experienced many repagination crashes as well in my attempt to create the test file.
Created attachment 177882 [details] BT without symbols I can confirm the crash Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4a388f5e01ebb5a512931d11e48c4380382239c8 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL Saving & opening the file at cursor position didn't work for me (bug 146988).. But scrolled down & put the cursor on the last page.. and opened a new Window
Created attachment 177884 [details] BT without symbols (for clicking inside document while loading) If you click around in the document, while it's loading you might catch an crash. Probably something to do with timing.. This unrelated to the STR but matches the observation at comment 0. Will need a separate report..
No need to inflate bugs, rather all should be tested in older versions to see if a regression.
On pc Debian x86-64 with master sources updated today, I got no crash but an hang when going at the end of the document. Here's part of bt: #9 0x00007faabea04a4e in SfxItemPropertyMap::getByName(std::basic_string_view<char16_t, std::char_traits<char16_t> >) const (this=0x7faaaa448980 <SwUnoPropertyMapProvider::GetPropertySet(unsigned short)::aPROPERTY_MAP_TEXTPORTION_EXTENSIONS>, rName=u"CharWordMode") at svl/source/items/itemprop.cxx:67 #10 0x00007faaa8dd6d5e in SwUnoCursorHelper::GetPropertyStates(SwPaM&, SfxItemPropertySet const&, com::sun::star::uno::Sequence<rtl::OUString> const&, SwGetPropertyStatesCaller) (rPaM=SwPaM = {...}, rPropSet=..., rPropertyNames=uno::Sequence of length 75 = {...}, eCaller=SW_PROPERTY_STATE_CALLER_SWX_TEXT_PORTION_TOLERANT) at sw/source/core/unocore/unoobj.cxx:1854 #11 0x00007faaa8e1de0e in SwXTextPortion::GetPropertyValuesTolerant_Impl(com::sun::star::uno::Sequence<rtl::OUString> const&, bool) (this= 0x156dc390, rPropertyNames=uno::Sequence of length 75 = {...}, bDirectValuesOnly=true) at sw/source/core/unocore/unoport.cxx:590 #12 0x00007faaa8e1ea73 in SwXTextPortion::getDirectPropertyValuesTolerant(com::sun::star::uno::Sequence<rtl::OUString> const&) (this=0x156dc390, rPropertyNames=uno::Sequence of length 75 = {...}) at sw/source/core/unocore/unoport.cxx:566 --Type <RET> for more, q to quit, c to continue without paging-- #13 0x00007faaa8e1eaff in non-virtual thunk to SwXTextPortion::getDirectPropertyValuesTolerant(com::sun::star::uno::Sequence<rtl::OUString> const&) () at sw/source/core/unocore/unoport.cxx:567 #14 0x00007faab6810ca6 in (anonymous namespace)::FilterPropertiesInfo_Impl::FillPropertyStateArray(std::__debug::vector<XMLPropertyState, std::allocator<XMLPropertyState> >&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, rtl::Reference<XMLPropertySetMapper> const&, bool) (this=0x207f4860, rPropStates=std::__debug::vector of length 0, capacity 0, rPropSet=uno::Reference to (SwXTextPortion *) 0x156dc3c8, rPropMapper=rtl::Reference to 0x1372ce40, bDefault=false) at xmloff/source/style/xmlexppr.cxx:263 #15 0x00007faab6810284 in SvXMLExportPropertyMapper::Filter_(SvXMLExport const&, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const&, bool, bool) const (this=0x2a7d7f20, rExport=..., xPropSet=uno::Reference to (SwXTextPortion *) 0x156dc3c8, bDefault=false, bEnableFoFontFamily=false) at xmloff/source/style/xmlexppr.cxx:642
After having waited for the end of hang, the file saved, I closed it and reopened but was still at the beginning instead of the end of the file. Then I scrolled 3 times from first page to last page, no crash.
Regression introduced: https://git.libreoffice.org/core/+/51379fb3d46e5891bdaea0122bd62b0753663da3%5E%21 commit 51379fb3d46e5891bdaea0122bd62b0753663da3 [log] author Caolán McNamara <caolanm@redhat.com> Thu Dec 03 15:54:45 2020 committer Caolán McNamara <caolanm@redhat.com> Fri Dec 04 15:57:41 2020 tree 6c9e85ed41e6999bb3d9c5331da05dee2141ef0b parent 30c54afbf5bf03da27db7f90b518817cd05e8ccd [diff] Bibisected with: bibisect-win64-7.2 Adding Cc: Caolán McNamara
@csyu.279 does that windows crash still occur in the latest release? It might have been solved with bug 147802
Using the original file (>2000 pages, >2MB), it's no longer crashing for me.
@Caolán McNamara it doesn't crash in the latest version of Libreoffice. Thank you!
sounds like the same problem them, running out of windows resource handles