Summary: | Copy/Paste of a column in Calc file followed by Cmd-Q causes soffice process to consume all resources | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | mercergeoinfo |
Component: | Spreadsheet | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | QA Contact: | |
Severity: | major | ||
Priority: | high | CC: | erack, iplaw67, kyoshida, markus.mohrhard |
Version: | Inherited From OOo | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Mac OS X (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
sampling trace
timer trace ODS test document |
Description
mercergeoinfo
2013-09-17 10:15:43 UTC
Sorry, can not confirm on OSX 10.8.4 with LO 4.1.1.2 Please provide details : OSX version LO / AOO / NeoOffice version Alex LibreOffice Version: 4.1.1.2 OSX 10.7.5 But I have had this issue for some time, using OSX 10.6 and many versions of OO/LO/NeoOffice and it is specifically triggered by quitting directly after saving a csv file with "Save as" and "Edit filter settings" even if using the default settings. Also, which CSV export settings are you using ? A minimum size ODS file which you use to reproduce the problem would be necessary, otherwise we'll be running around all day trying to find out the specific cause. I'm not saying that the behaviour you observed doesn't exist, just that I can't reproduce it, nor have I ever seen this, whether it be with LO, AOO, or Neo, and I've gone through 3 OSX upgrades in as many years from 10.6, to 10.7 and now to 10.8. This would indicate on the face of it that there is something specific, either in your configuration files, or in the data that you are attempting to export, which causes the problem. Alex Just tried with AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:51:10 (Tue, 16 Jul 2013) No hang there either. 1) Start OOo app 2) Open new Calc document 3) Enter some text in A1 4) Enter some numbers in B1 5) Enter a number with decimals in C1 6) Enter a date in D1 7) Save as CSV - choose default export options 8) OpenOffice main menu > Quit I did exactly the same with LO. You need to provide us with that kind of detail, so we can try and reproduce. Use cmd-Q to quit, no interaction with NO's GUI, that's what triggers it. I can avoid the crash by quitting via the menu but sometimes I'm in my "flow" and just use keyboard shortcuts, forgetting that disaster awaits. So, tried again and had some difficulties but managed to get a close match to the behaviour. csv file of 1kb Open in LibreOffice Swap two columns Save as Edit Filter Settings Press Enter key to save then cmd-Q to quit I had prepared beforehand by closing everything else down and having the Force Quit window open. This eased the problem but it certainly triggered a crash in LO Re previous comment about config file: I always clean install so it seems unlikely. Also, I think, though I cant be certain, that I had this issue with OO on 10.5 OK, I can reproduce now, but only : - if I import an existing CSV file ; - if I copy and paste one or more columns to another column position ; - then use Cmd-Q to quit the application Memory consumption of the soffice process steadily climbs over time, seemingly as 5 or 6 threads are polled/respawned, and memory continuously allocated. Changing title to reflect findings. Alex Adding Markus, Kohei, and Eike to CC Lifecycle memory allocation problem ? Alex Correction : after more testing, the problem can be reproduced with native ODS Calc documents too. Created attachment 85983 [details]
sampling trace
Sample trace after Cmd-Q with soffice process still running
Created attachment 85984 [details]
timer trace
timings of process threads/calls after Cmd-Q is issued and soffice process still running
How to reproduce : 1) Open attached ODS test file 2) Select a whole column by clicking on column header 3) Copy/paste any column to another empty column 4) Save 5) Quit the application (Cmd-Q or LibreOffice > Quit) Watch how the soffice process remains running, maintaining 5 or 6 threads, consuming processor availability til it hits 100%, at which point the OSX process monitor kicks in and states that the application is no longer responding. The processor occupancy drops, but memory continues to be allocated to the soffice process. Alex Created attachment 85988 [details]
ODS test document
Upping priority as the only way to escape this is to force kill the application. I have only tested this back to LO 3.3.4, so can't say at the moment whether it does go back to OOo times Confirming also in OOo 3.2.1. Changing version back to Inherited from OOo |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.