I was editing a document of about 16,000 words (so, relatively short). I had just moved a word into the wrong place (sloppy mousing dropped the word on the line below where I wanted it), so I moved the still-highlighted word where I really wanted it. A few seconds later when I double clicked on the word again, the text changed to display other parts of the sentence. When I deselected the word, the wrong text disappeared and the text as I expected it to look, was displayed correctly. I did a Ctrl-S to save and Writer immediately crashed, saying a fault had occurred and my documents would be recovered. All the documents I had open that I had not recently changed were recovered: Writer simply said that recovery had failed on the document I'd been working on. None of my edits had been saved, so I lost about 30 mins of careful work and creative adjustments. I'm also disappointed that there was no auto bug report prepared for the crash. If I can't rely on Writer not to lose work, I'll have to stop using it. Reliability is a critical feature. I appreciate that this bug report is probably inadequate to reproduce the bug, but felt I should report the crash and data loss. Perhaps it relates to https://bugs.documentfoundation.org/show_bug.cgi?id=138830 ?
I just remembered another really weird error that occurred in the minutes leading up to the crash. I had inserted a clause into a sentence before an apostrophe, and all the words appeared in the correct place, but all the spaces between the words had appeared in front of the apostrophe, I noticed when I looked up at the screen. Something like: 'What an idiot', she thought. --> 'What an idiot.Ishoulddosomethingaboutit. ' so I had to manually delete the excess spaces and insert them where I had typed them originally: 'What an idiot. I should do something about it.' I hadn't noticed any excessive load on the machine, though it's possible it had been busy. I was astonished that such a result was possible. I can't imagine how keyboard input is handled, to allow that as a possibility. I've never seen it in any program ever, before this. But it had happened only a few minutes before the crash. It reminded me of a bug in Writer (which I think is now fixed), in which text typed when the machine was under heavy load would be inserted in apparently random order into the document. But that applied to all characters, not just the spaces.
Also perhaps related: I just had a brief period in which the displayed text did not match the text as I edited it. I had the text: but be at his office at six fifteen a.m – he’d been quite precise – about the time, and about waiting to be called in. I wanted to break the sentence, to create: but be at his office at six fifteen a.m. He’d been quite precise – about the time, and about waiting to be called in. But several times, when I put the insertion point after the 'm' in 'a.m', and selected from there up to and including the 'H' of 'He', then typed a period and two spaces, what resulted was the text: but be at his office at six fifteen a.m .He’d been quite precise – about the time, and about waiting to be called in. Soon after that, I was unable to sweep or otherwise select a block of text: the selection did not highlight. I had to click away into another window and then back again, when suddenly the text I'd selected appeared highlighted. This was in the MATE desktop. Hope these clues might help.
The wrong display (shifting of spaces) has just happened again. I had: Assuming [...] I selected just the 'A' in 'Assuming' and typed "Of course, that a" but instead of getting: Of course, that assum[...] Writer produced: Ofcoursethata , ssuming
I don't know if it helps, or is related, but this version of Writer also regularly red-underlines words as if they're spelled wrongly, because you edited them. I've submitted a separate bug report for that (147335).
I just had another crash. I'd guess a different cause though, it said std::array_new_length I think (maybe "bad std::array_new_length") Again, none of the last 30 mins of my editing was restored after I started Writer, though it claimed it had recovered the file this time. That hadn't happened to me for a couple of years now. This appears to me a serious regression.
I've upgraded to 7.3.0.3 - I'll see if any of these problems recur.
The weird jumbling of the characters typed, separating out the spaces from the other characters, is still happening in version 7.3.0.3. It's really annoying.
Latest example: I selected the "T" in "The" and typed She didn't l but Writer produced: Shedidntl ’ he So it moved the first space (between "she" and "didn't") to some separate buffer, then added the apostrophe to the end of that buffer, then removed the next space from the input stream (between "didn't" and "l[et]") and inserted it in front of the apostrophe there; then when I paused, it output that buffer at the end of the characters I'd typed. Bizarre.
I'm thinking the input jumbling is a separate bug: let me know if you feel I should file a separate bug report for it.
(In reply to Luke Kendall from comment #0) > Writer simply said that recovery had failed on the document I'd been working > on. > None of my edits had been saved, so I lost about 30 mins of careful work and > creative adjustments. Ouch, I know the feeling. Also aware of the recovery not always delivering the desired result.. :-( -- I suggest a user profile first, because there should be plenty of reports if your description would be common(there are non) and I'm also experiencing the trouble you do https://wiki.documentfoundation.org/UserProfile
Created attachment 178225 [details] Output of ls -RC ~/.config/libreoffice/4/user/extensions/
Interesting, thanks. I've restarted in safe mode and I'll see how it goes. I discovered, doing that, that I apparently had Record Changes turned on (I didn't mean to), but I'll leave that on and see if the problem persists. If it does, I'll try turning it off and seeing what happens. Thanks. I don't think I have any extensions installed, but I'll attach and ls -CF of ~/.config/libreoffice/4/user/extensions/
So, after a few hours of editing in safe mode, I didn't experience any examples of the input jumbling, but it did just crash mid-editing again. (Version 7.3.0.3) At least this time it produced a crash report, and I had saved not long before the crash, so I didn't lose much work I think. The crash report is at ... rats. I did a Ctrl-C of the URL, but it apparently didn't work. The crash was about 4 minutes before I added this comment, if that helps find it?
Having restarted Not in safe mode, a similar but different strange editing behaviour is happening. Twice in the last few minutes I've selected some text and typed replacement text, and Writer has added a second copy of the text I just typed. E.g. I selected the word "leg" and replaced it with the word "foot", and Writer produced "footfoot" Then I deleted "feel of" and made another correction, then decided to type in "feel of" again. After I typed the "of", the text appeared doubled to "feel offeel of" Since I can show this at least by undoing and redoing, I made a small screen recording of it. I'll attach that: 147332-TextDoubling.mkv
Created attachment 178249 [details] Short sceren capture of the weird text-doubling behaviour
And another crash, mid composition, maybe ten minutes work lost. Crash report is https://crashreport.libreoffice.org/stats/crash_details/76b0ac23-2426-4ff7-abac-1da9731d0e98 (Yeah, Ctrl-C of the text from the crash panel doesn't work in MATE desktop, glad I took extra care to save it this time.) I think I'll have to revert to an earlier version of Writer, this one is just too unstable for use.
Oh, on a shell window I noticed this from (I think) the first crash, with 7.0.5.2: LibreOffice 7.0 - Fatal Error: std::bad_array_new_length
(In reply to Luke Kendall from comment #15) > Created attachment 178249 [details] > Short sceren capture of the weird text-doubling behaviour Thanks for all the testing.. and feedback/screencast. However if have hard time making sense of everything happening.. Number of questions * The cursor is between "oily grid" next oily replaced by 'feel' (but no clue what happened in between) * Is it possible to reproduce the problem with the exact same steps as seen in the screencast? * Are you working with Track & Changes on or off? * Is this LibreOffice 7.0.5.2 is from LibreOffice.org or distro build?
Found something.. Have moved it to bug 147402 for readability
"Number of questions" * The cursor is between "oily grid" next oily replaced by 'feel' (but no clue what happened in between) Originally, I deleted "feel of " from in front of "oily grit". I then corrected "he" to "her". Then I decided it was better with "feel of " there. Since I had deleted it, not cut it, I re-typed "feel of " before "oily grit", but after typing the "f" in "of", the words appeared twice. The video shows me undoing and then redoing to help show what happened. * Is it possible to reproduce the problem with the exact same steps as seen in the screencast? I doubt it, the behaviour seems to happen randomly. At first I thought it happened only with spaces (and apostrophes) and was somehow related to smart punctuation replacing an ascii ' character with an apostrophe, as originally all occurrences seemed to relate to spaces being stripped from between words and added at the end of the typed sequence. (Well, spaces plus the apostrophe.) But the video shows text doubling, which seems to happen randomly. * Are you working with Track & Changes on or off? Yes, I have Track Changes on, to see if it crashed even in Safe Mode: I wanted to change as little as possible. After that crash, I forgot to turn Track Changes off, and had the extra crash. Both of the last two produced a crash dump which I hit "Send" for. I only had a copy of the URL for the last one though. * Is this LibreOffice 7.0.5.2 is from LibreOffice.org or distro build? I'm not certain but I'm pretty sure 7.0.5.2 was a Libreoffice.org build, as their releases are more frequent than those of the distro. I'm 100% certain the 7.3.0.3 build was from LO.org. I have also seen text change on screen unrelated to my edits: the text looking wrong (as if the text was rendered in the wrong position in the paragraph), and vanish after undoing and redoing. This greatly reduced my confidence that I could trust that what I could see was what the text in the file actually had. On top of the frequent crashes and data loss, it encouraged me to stop using 7.3. I have now reverted to LO 7.2. Hope this helps a bit. I hope the crash report(s) I mentioned help, too.
@Luke Already discovered 3 issues with track & changes and editing turned on :-( Happening with basic editing... So enough potential to make it crash even though I'm unable to reproduce that Issues are present since LibreOffice 6.2 (major redesign of track changes code). I would suggest to avoid using Track & Changes until number are 'improved'.
Thanks very much for the warning Telesto, I'll turn it off!
@Luke The bad std::array_new_length crash is likely bug 140077
This report is long and stays Unconfirmed. Is there anything here that should be summed up in reproducible steps?
Dear Luke Kendall, 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 Luke Kendall, 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