After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 634135 - Hang or taking-way-too-long on ods save
Hang or taking-way-too-long on ods save
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: import/export OOo / OASIS
git master
Other All
: Normal normal
: ---
Assigned To: Andreas J. Guelzow
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-11-05 23:41 UTC by Morten Welinder
Modified: 2010-11-06 04:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
foo.ods (507.31 KB, application/octet-stream)
2010-11-05 23:42 UTC, Morten Welinder
Details

Description Morten Welinder 2010-11-05 23:41:28 UTC
Extracted from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602257

1. gnumeric foo.ods
2. File->Save
***time passes***
Comment 1 Morten Welinder 2010-11-05 23:42:03 UTC
Created attachment 173926 [details]
foo.ods
Comment 2 Andreas J. Guelzow 2010-11-06 00:31:22 UTC
1 million formatted rows will take a while:

  • #1 odf_write_content_rows
    at openoffice-write.c line 3240

Comment 3 Andreas J. Guelzow 2010-11-06 00:34:47 UTC
If I recall correctly then at some time we combined all the empty rows but run into problems with the formatting. What we should really do is figure out whether rows are identical in style _and_ content without having to look at each of them.
Comment 4 Andreas J. Guelzow 2010-11-06 00:45:03 UTC
Strange,when this file was saved the first time we knew that there was no content in the last 983039 rows and that they were all of the same style and we wrote in odf_write_styled_empty_rows:

<table:table-row table:style-name="AROW-2" table:number-rows-repeated="983039">
<table:table-cell table:number-columns-repeated="1024" table:style-name="ACE-0x818b2d8"/>
</table:table-row>

When we open it and save it the second time we are trying to save all those rows one-by-one in odf_write_content_rows.

So the problem could as well be in the opening of this file.
Comment 5 Andreas J. Guelzow 2010-11-06 00:52:08 UTC
When saving the issue lies with:

extent = sheet_get_extent (sheet, FALSE);
...
style_extent = extent;
sheet_style_get_extent (sheet, &style_extent, col_styles);

while extent is reasonable:
(gdb) p extent
$1 = {start = {col = 0, row = 0}, end = {col = 11, row = 2050}}

style_extent becomes to large although the common style should be stashed in col_styles:

(gdb) p style_extent
$2 = {start = {col = 0, row = 0}, end = {col = 1023, row = 1048575}}
Comment 6 Andreas J. Guelzow 2010-11-06 04:52:14 UTC
This in fact wasn't the problem. We are only calling sheet_style_get_extent to get the col_styles. We incorrectly and unnecessarily tried to handle hidden and collapsed rows separately.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.