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.
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.
@ercolinux: Please contribute a sample document. If it's too big for an attachment or confidential, you can send it to me as email. @Kohei: Can you find useful information in the attachment?
I received a sample document from reporter, will post my results tomorrow.
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.
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 3.3.2.2)]" 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. @ercolinux 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! @Kohei: 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.
@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.
[Reproducible] with reporters confidential sample document "GeConsunt-prevent.08.xls" "LibreOffice 3.3.2 – WIN7 Home Premium (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]" 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. @ercolinux: Do you agree that I forward your document to Kohei for more detailed debugging?
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)]"
@Rainer: Yes, you can forward the xls to Kohei.
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%.
(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
Ok. This is still reproducible in the 3.4 build. I'll take a look.
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...
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.