Bug 73813 - 'Adapt row height' process sometimes takes 8 to 10 minutes to complete on a 156,000 line .ods
Summary: 'Adapt row height' process sometimes takes 8 to 10 minutes to complete on a 1...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Windows (All)
: medium major
Assignee: Not Assigned
Depends on:
Reported: 2014-01-19 23:09 UTC by David Carter
Modified: 2014-06-04 22:24 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description David Carter 2014-01-19 23:09:21 UTC
Hi ThudDriver, I saw your edit at Adapt row height as I'm an admin and you hit a abuse filter by accident. The page was sadly not saved. Your content was:


Calc hangs - status/progress bar at bottom shows "Adapt row height" and the green progress bar moves steadily to about 80% of the way to the right and stops. Sometimes it will complete the action in 8, 9, or 10 minutes. But today, 14 Dec 2013, I waited over an hour and it never completed. Had to "kill" the program and re-open the file. Now I am unable to delete a column. The task manager shows soffice.bin consuming 50% of cpu resources.

My operating system is WinXP Pro, 4mb memory, so memory is not a factor.

I'm working with a large voter data file in .ods file format with 159,146 lines, imported from a .csv file.

I did extensive editing and formatting of columns last 3 days, with lengthy delays (8 to 9 minutes) for the 'Adapt row height' process to complete after formatting a column or deleting or cutting and pasting a column to move it. Sometimes there was no delay and the "Adapt row height" process was never displayed.  Thus, there is some manner of "variableness" in this problem.  It is not a consistent thing, but very vexacious and time-consuming when it strikes.

There is no reference to "Adapt row height" in downloaded Help, on-line Help for LibreOffice.


Thanks for reporting, but sadly you reported your bugs at the wrong place. Please take the time and report the bug again at https://bugs.libreoffice.org/ or ask for assistant at a mailing list.


Regards, Dennis Roczek (talk) 2014-01-18T01:20:51 (UTC)

I notice there are other similar reports, 2 of which mention consuming all the memory.  My problem always showed exactly "50%" of CPU resources in the Task Manager.  A couple of the reports said "Hung" - I have learned from long experience to "wait" a long time to see if a process will complete, which mine did in all cases except 1 which did not complete in over an hour so I killed it and re-opened the file.

I notice that almost all the above reports were closed "works for me".  So, I am submitting a new report which has different characteristics and, hopefully, additional detail.

Speaking of more detail, this "event" where "Adapt row height" occurred would happen when I'd reformat a column, when I'd insert a column, and when I'd "cut" a column to "paste" into the previously created blank column.  The result was 3 8 to 10 minutes waits for each of the 3 acts to get a column to be where I wanted it and displayed as I wanted it. 24 to 30 minutes per column.  "Major"?  or "Severe".  But, it didn't always happen.  I could go for many columns and wouldn't see the "Adapt row height" progress line or it would complete in perhaps 10 seconds.  I cannot identify any difference in what I was doing that could be causing the long "process" of "Adapt row height".  Again there  is no mention of "Adapt row height" in "Help" or anywhere else, except the bugs that have been submitted and closed as "Resolved - worked for me".  It is obviously not just me or the other 6 or so people who have experienced this.

If you want the large file I'm working on (a voter registration file)I could copy to a dvd or cd and mail it to you.  I'm not sure I can send the ods file as an attachment to an e-mail due to e-mail limits on attached file sizes:  My file is 43,617,000
. . . I'll try to attach to this report.
Comment 1 Dennis Roczek 2014-01-24 12:26:08 UTC
just FYI: this was a report in the wiki which wasn't saved because of an edit filter (also called abuse filter) as mentioned in my talk page message onwiki ( https://wiki.documentfoundation.org/User_talk:ThudDriver ).

The user left a mail address and other things for the case we have to contact him directly. Until now he hasn't responded onwiki. I left a link to this bug report for him on the wiki for now.
Comment 2 tommy27 2014-02-23 08:07:49 UTC
upload test file to some webhosting site and provide a download link.
otherwise it will be impossible to test and debug.

set status to NEEDINFO
Comment 3 bfoman (inactive) 2014-06-04 22:24:21 UTC
LibreOffice 4.1.x is in EndOfLife state and there. Considering no contact with original wiki reporter, I think this bug report should be closed as INVALID stagnant report. 
I you ever visit this report and confirm that issue is reproducible in latest stable version of LibreOffice please file a new report.