Apache OpenOffice (AOO) Bugzilla – Issue 62028
OO hangs for ca. 30 sec when editing a big table in Writer
Last modified: 2013-08-07 14:38:26 UTC
In Writer I had a table with 2 colums and inserted text with hyperlinks. The table then was about 52 pages. In the first row several cells where merged into on cell. Then I made two new columns. When trying to modify the width of the two new columns, it was impossible to get narrow with use of the cursor. Trying to mark the third column at the head of the column just shaded the second, not the third column. OO hanged. With Task-Manager CPU-load was 100% for several minutes (after all I had to kill OO with help of the Task-Manager. Even after a restart there are still the same problems with the table. If you like I can send you the file with the table. It seems that with complex tables there is some disturbance within the logic and it leads to an indefinite loop.
Created attachment 34132 [details] Document with the table that causes the errors
Sorry Not: In the first row several cells where merged into on cell. But: In the first column several cells where merged into on cell.
I have found the reason why it does not work as expected. Have a look on page 32, the row containing ".XSQLData". There are splitted cells preventing from the desired resizing process. Merge these into the suitable cells and it will work again.
Closed.
Even after removing the row with the strange cell-formatting OOo hangs from time to time. After some time of inserting text OOo gets 100% CPU-Load for about 2 minutes (CPU 3.0 GHz Prescott, 2 GB Main Memory - only OOo + Firefox with the OOo Docu running). Then it comes back - and hangs up again after a while. It seems that there is something running in the background (spellchecking and autoformat switched off).
MRU->FME: This is a very nasty thing when editing large tables. Here we now have a sample where it is easily reproducable. When e.g. entering text so that the line ina cell breaks, Writer needs about 30 sec to be accessible again. This issue might be related to issue 46078.
*** Issue 61557 has been marked as a duplicate of this issue. ***
I wouldn't consider Issue 61557 to be a duplicate at all. Although the common factor is long tables with some cells merged, there are four MAJOR differences: 1. In my case, the "hang" is NOT 30 seconds-- It's far far longer (indfinitely long: sometimes I have waited for half an hour before killing OOo, as there was no indication when it would end). 2. My 2-column table has merged cells across columns in some rows (to accommodate large images that take up the full width of the page) 3. My PC is HT-enabled, and it shows 50% load for one of the two CPUs (the other does show heavy load, but not 50%). 4. In my case, the hanging is not related to column-width-adjustment at all: It occurs even if I do NOT edit the document in any way; but rather happens if just try to scroll to the bottom of the document. But the strange thing is, it does NOT hang if I go towards the bottom of the document using the navigator (i.e., by clicking an item that is near the bottom.) Once I jump like this, I can move freely in the document without fearing a hang.
I did some more tests to get you on the track. 1. the error with column-width-adjustment seems not to be the cause of the error with OOo freezing. 2. OOo freezing occured with a large table (with a lot of hyperlinks) in View/Printlayout. In View/Weblayout it seems to be absent or very short. 3. In Task Manager at the beginning of the freeze you can see cpu load rapidly going to 100% for a while (duration depending on the complexity and length of the table), then a very short increase (just enough for a few keystrokes that are still in the buffer to be interpreted) and then again 100% cpu load for the same time as before. The diagramm looks like a "M" with a short middle-pin. I hope it helps you in your investigation.
I double-checked MY earlier observation#3: It seems in my case too the CPU load reaches 100%. When I observed the CPU patterns closely, I found they had some correlation. Then I captureed the load graphs for both CPUs; and then inverted one of the graphs. Both graphs turned out to be exact opposite of each other! When totalled, they make up 100%. I guess that means a total load of 100%? (Is that how a HT-enabled PC shows the CPU load?)