Bug 36051 - FILESAVE of particular big .xls spreadsheets freezes LibO
Summary: FILESAVE of particular big .xls spreadsheets freezes LibO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.2 release
Hardware: x86 (IA32) Windows (All)
: medium critical
Assignee: Kohei Yoshida
Whiteboard: target:3.4
Depends on:
Reported: 2011-04-07 07:16 UTC by ercolinux
Modified: 2013-11-24 19:25 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:

result of strace on Linux PC (5.60 KB, text/plain)
2011-04-08 00:50 UTC, ercolinux

Note You need to log in before you can comment on or make changes to this bug.
Description ercolinux 2011-04-07 07:16:01 UTC
I've some big spreadsheet (15-20MB), whenever I try to save and close one of it, calc took a long time to save and then wait for 10-15secs before exit.
If I've modified some cells pulling the contents from nearby cells instead of only write new values it freezes for 5-10 min after the end of the save before close . If I kill libreoffice (even just after the end of the save) when I reopen the file I find the change I made.
The PC remain responsive during the wait, only libreoffice freezes. This occours during autosave too.
I've found this problem both in windows and Linux version, and with differents files of big size.
Trying to save in odf is a pain: more then 3 minutes to save but when it finish calc is closed in 10 secs.
With smaller files (up to 3-4MB) it close just after the end of the save, no matter which format I choose.
The time it tooks to close is nearly the same on a single core 2.2GHz CPU up to a dual core 3.3GHz CPU; tested with 1 2 and 3,5 GB of RAM, both on local drive or network share.
Comment 1 ercolinux 2011-04-08 00:50:54 UTC
Created attachment 45412 [details]
result of strace on Linux PC

I've enclosed the strace output from the point in which the advancing bar of the saving process finish to the kill of the program. 
From the lines 
munmap(0xb3bbf000, 4096)                = 0
munmap(0x953dd000, 42680)               = 0

to the line in which I've killed the program:

--- SIGINT (Interrupt) @ 0 (0) ---

I've waited near 2 minutes.
Comment 2 Rainer Bielefeld Retired 2011-04-19 23:34:51 UTC
Please contribute a sample document. If it's too big for an attachment or confidential, you can send it to me as email.

Can you find useful information in the attachment?
Comment 3 Rainer Bielefeld Retired 2011-04-20 04:45:58 UTC
I received a sample document from reporter, will post my results tomorrow.
Comment 4 Kohei Yoshida 2011-04-20 06:00:12 UTC
BTW, whoever works on this needs access to the document as well, or else it would be impossible to do proper profiling.

And strace is not very helpful when diagnosing performance issue.
Comment 5 Rainer Bielefeld Retired 2011-04-20 10:19:49 UTC
Crash or hang problem NOT reproducible with sample I rot by PM and with "LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag]" on 64 bit AMD Phenom II X4 955 Processor 3.2 GHz, 4GB RAM, Graphic Card: NVIDIA GeForce GT 430. It's some hard work for the PC (also saving as xls and as ods) with a lot of HDD load, but after 30s work is done also for save as .xls as also for save as .odt.

I doubt that it will help, but may be you can contribute a step by step instruction containing every key press and every mouse click how to reproduce the problem with your sample? May be there is a little detail you are used to do in an other way that I do what causes your problem? Pls. send by PM!

I don't believe that ercolinux will have a problem with leaving his document to developers for bugfix, what is something completely different to have it published in the WEB.
Comment 6 ercolinux 2011-04-20 11:19:32 UTC
@Rainer: You've got my point: I've cleaned the sheet of most of the info but not sure if there is some hidden. And it can contain sensible data if related to the company that make the file. Anyway if any of the developer need it I can send them a copy.
To reproduce the bug in the sheet with most data I select a cell and pull the data in the cells below using the small black rectangle in the corner.
At this point saving and closing Libreoffice (both via menu/icons or closing it with the (X) icon in the bar) leads to a freeze of the PC: it tooks 30-40 secs to save the file with the progress bar that advance then it stops forever.
Any other way of input data in the sheet works.
BTW: the some sheet save and close in less than 10 secs with MSO 2003/2007.
Comment 7 Rainer Bielefeld Retired 2011-04-20 21:40:23 UTC
[Reproducible] with reporters confidential sample document "GeConsunt-prevent.08.xls" "LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag]"
Steps t reproduce (attention, LibO will hang!):
1. open document from WIN Explorer
2. scroll up so that you see cell 'D5' in sheet 
   "This one is the not working one"
3. click 'D5'
4. use Autofill to spread 'D5' contents to 'D5:D15' (Use autofill control point
   at bottom right corner of cell cursor 
5. Menu 'File > Close' (save in xls format)
   Expected: File will be closed
   Actual: Save process starts, progress bar appears and everything seems to   
           work, but after progress bar reached the end and disappeared, LibO
           will hang and not close.

I did not check many other edits before step 5 "close", but a simple addition of a character to 'D5' will not cause the hang, with that little edit the document can be closed without problem.

Do you agree that I forward your document to Kohei for more detailed debugging?
Comment 8 Rainer Bielefeld Retired 2011-04-20 21:51:14 UTC
Same problem with " Ooo 3.3.0  – WIN7  Home Premium  (64bit) German UI [OOO330m20 (build 9567)]"
and "Ooo-Dev 3.4.0 multilingual version German UI WIN XP: [OOo300m103 (Build 9578)]"
Comment 9 ercolinux 2011-04-20 23:39:35 UTC
@Rainer: Yes, you can forward the xls to Kohei.
Comment 10 ercolinux 2011-04-22 00:02:58 UTC
I've made further tests with beta2. Now seems to works but I got an error on exit: 
The instruction at "0x04326546" referenced memory at "0x0000004", The memory can't be "read".
A part from error the file is saved correctly.
BTW I've found that during the file save only 1 core of the cpu go to 100% the the others stay at less than 5-10%.
Comment 11 Volker Merschmann 2011-04-22 06:28:58 UTC
(In reply to comment #10)
> A part from error the file is saved correctly.
> BTW I've found that during the file save only 1 core of the cpu go to 100% the
> the others stay at less than 5-10%.
This is a known bug of beta2, bug 36301
Comment 12 Kohei Yoshida 2011-05-03 17:08:08 UTC
Ok.  This is still reproducible in the 3.4 build.  I'll take a look.
Comment 13 Kohei Yoshida 2011-05-03 18:18:18 UTC
To reproduce a hang, it's sufficient to do the autofill, then close the window without saving the change.  It's entirely tied to the autofill action that causes the hang; it has nothing to do with the saving of the file.

It appears that whatever we are trying to do there is incredibly inefficient...
Comment 14 Kohei Yoshida 2011-05-03 19:25:18 UTC
Ok.  I ended up cleaning up the old code that was not doing anything meaningful.  Its removal also made the reported performance issue go away.

This is now fixed in the 3.4 branch.