Apache OpenOffice (AOO) Bugzilla – Issue 8518
swriter hangs after text cut
Last modified: 2013-08-07 14:43:23 UTC
I have a document (which I will attach) On the first page, when I select all the text below the table to the end of the page and then chose from the menu Edit->cut the swriter program hangs. In fact the mouse moves but I can't do anything with it. I can't select another window in the same desktop (gnome desktop) or select another desktop from the desktop pager. I can use ctrl-alt-F2 to switch to another virtual terminal. I see there that soffice.bin us using 95% of the CPU time according to top. I killall -9 soffice.bin there then I can switch back to the X virtual terminal and continue working. I have reproduced this multiple times. It also happens when I select the text and press the "delete" key.
Created attachment 3241 [details] this is the document referenced in the issue doc.sxw
Correction: if I select the text on the first page under the table to end end of the page and press the "delete" key, I can select other windows but the swriter frame is hung. It doesn't update and I cannot select any menus or operations within swriter. If I put another window on top of swriter then move the swriter window, the contents of the other window move with it.
A similar behavior also happens on Windows 98. I select the text below the table on the first page to the end of the page and choose Edit->Cut. The swriter window is hung at that point. I cannot select any menus or do anything in the swriter window. If I bring up other windows on top of swriter and move them, the exposed portion of the swriter window does not update. The only way of killing swriter is with the task manager that you bring up with Ctrl-Alt-Delete.
Eric, thank you for using and supporting OOo. Duplicated on Win NT 4.0 SP6a, OOo 643. On the first page, select the text underneath the first ( and only ) table and Edit->Cut or press delete. OOo hangs for me.
The problem in this document is the enormous amount of recorded changes. Have a look at "Edit-Changes-Accept or reject": Eric was editing this document with different user names, maybe with different installations, maybe on different platforms. Debugging brings up a loop of the assertion "overlapping redlining". As expected, accepting all changes before deleting the text solves the problem. SBA->DVO: In 644, this assertion still comes up only once (doesn't loop anymore).
*** Issue 9195 has been marked as a duplicate of this issue. ***
dvo: I'll try to fix this for the upcoming beta.
dvo: Fixed in sw006 (target for OOo 1.1 release) docredln.cxx v1.21.72.4 The problem was a look in SwDoc::AppendRedline. In the document, there was a situation roughly like this: [...deleted...]|xxx Where [...] is text from a deleted redline | is en empty delete redline xxx is text which is about to be deleted When processing this, AppendRedline would find that the new redline and the existing ([...]) redline could be merged, and did so without regarding the empty redline in between. When processing the merged redline, it would decide that it needs splitting up because of the empty redline and split the redline into its original parts. And then from start... This bugfix simply deletes empty redlines, but I think a more robust method would be to improve merging of redlines., i.e. improve SwRedline::CanGroup to take intermediate redlines into account.
US->HBrinkm: as said reopened for verification and chown.
.
Ready for QA
SBA: Fixed in CWS SW-006
SBA: Set to verified.
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.