Description: I have a directory with large word processing research files in Libre Office Writer. For the last several weeks, when I open SR_P.odt (one of about 20 such files) and do a search, the screen moves to within a page or two of the target, but never the correct spot. When I try to scroll up or down, it keeps returning to the same place. Sometimes I can move the right-hand slider bar and then scroll to the proper location, but often this does not work. Occasionally I can modify and save the text, but usually it crashes the entire program. Recovery works, but the problem with that specific file persists and may be getting worse. The other files in that directory do not seem to be affected, and all my other work (I am a college professor, so there are many of them) is not affected. I have been using Libre for about six years and, aside from minor glitches, this is first persistent problem I have encountered Steps to Reproduce: 1.Open C:\Users\Tobias Green\Dropbox\New folder\Dropbox\DBoxDocs\IFL Inc\SocReg_odt\SR_P 2.Search for some text 3. Actual Results: The search results in going to a page near the target text, but not the correct one. Scrolling (usually need to go upward) lands you back on the same page. Moving the right-hand slider bar up or down a little lands on a nearby page and sometimes you can then scroll back to the target text, but this works only occasionally and seems to be working less often. Expected Results: Libre Office Writer crashes, necessitating a recovery. After it has been recovered and closed, returning later to that specific file (SR_P) produces the same result. Reproducible: Always User Profile Reset: Yes Additional Info: Found the target text, permitted editing, then allowing me to save and close the file. Then, obviously, to reopen in it edit.
I copied the URL for the bug report, but then copied the full file name to include in my report, overwriting the bug URL. I don't know how to find it again, but will report it the next time this happens (unless you have a fix before then).
Thank you for reporting the bug. To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
I reset user profile as requested, but the problem persists in this file.
Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 155280 [details] A word processing file of biographical, economic, and social data arranged by individual names of elite persons in the US. I have been building this database for about fifty years. Currently, the information is all text based on individuals, arranged like a Who's Who or other biographical reference book. This file is the entries for the letter P.
To reproduce the bug, please search for a term like "PELL, George H" that should bring you to the page BELOW that entry (which is an error, should go directly to the term), then when you try to scroll up to the term, the program returns you the incorrect page (another error).
Problem seems to be increasing - now another file (SR_Ba-Bl) opens with the cursor somewhere in the middle of document rather than at the beginning. I have a free copy of Word 365 from my college (never use it except on its computers when I am teaching), but I have opened these two files (presumably corrupted in Libre) in Word and they seem to work properly. (I am committed to open source software and have been using Libre for a number of years, and do not want to abandon it - this reference to Word is for just for your information.)
(In reply to Tobias Green from comment #6) > To reproduce the bug, please search for a term like "PELL, George H" that > should bring you to the page BELOW that entry (which is an error, should go > directly to the term), then when you try to scroll up to the term, the > program returns you the incorrect page (another error). I tried to reproduce it. Your document is realy huge (141.750 words and 31.171 pages). Sometimes LO becomes unresponsive. Search result for "PELL, George H". First entry seems to be on page 11390. - Starting from page 11389 I get correct result. - Starting from the beginning, cursor jumps to page 11413 Tested with Version: 6.4.0.0.alpha1 (x64) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded => NEW Tobias, you write, that LO crashes. Does this mean, that LO becomes unresponsive or does it really crash? If this is the case, please add link to the crash report.
The problems vary - sometimes LO just stops responding, sometimes it stalls and then crashes. I linked to crash report when I filed this. I will send links if you can tell me where to find them. A bigger issue for me now is: if you consider this a huge file, should I abandon LO as my word processing software? I have been building this data for many years, and have been using LO for at least the last five years with good results, but if the program can't deal with files this big, maybe I should (very regretfully) return to Word.
(In reply to Tobias Green from comment #9) > The problems vary - sometimes LO just stops responding, sometimes it stalls > and then crashes. I linked to crash report when I filed this. I will send > links if you can tell me where to find them. If you restart LO after a crash, a window pops up and you will be asked, if you like to send a bug report. Send it and copy the link to the crash report. > A bigger issue for me now is: if you consider this a huge file, should I > abandon LO as my word processing software? Yes, I would call a document with more than 30.000 pages a huge file. But I don't have experiences with such huge documents. So I can't answer your question.
I have filed at least three crash reports over the last month, but don't know how to find their locations. But here is some interesting information. I assumed your 30,00 page count for the file is crazy, so went to check. I imported the file into Word to see if would work properly. So far, its does. The file size in LO (SR_P.odt) is 1.71 MB; the file in Word (SR_P_Word) is 1.97 MB. However, the number pages in the LO file is indeed over 30,000 (TEN TIMES the page count of my other similar files of about that size, for example SR_L.odt is 1.75 MB and 2480 pages), while the Word file is 2365 pages. I assume that this extreme difference in page count (but not in file size) for SR_L.odt might be significant?
(In reply to Tobias Green from comment #11) > I have filed at least three crash reports over the last month, but don't > know how to find their locations. Just open Search page in Bugzilla (see on top of this page), then open "Search By People" and enter you email-address.
I have tried searching for crash reports, all it does if refer me back to this case. I must be doing something wrong in the search.
Is anyone working to resolve this problem? Do you need more information from me?
Tested again with Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL After a long time document is reduced to 2531 pages and I couldn't reproduce the problem anymore Tobias, could you please retest with actual version of LO?
Dear Tobias Green, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Tobias Green, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp