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