When using the mail merge wizard in the tools menu to create a mail merge with a large amount of entries (approximately 2000), and selecting to save the results as individual documents WindowServer uses an increasing amount of memory (as much as 70 gigabytes) until it crashes.
Steps to Reproduce:
1. From form letter, goto "Tools" > "Mail Merge Wizard..."
2. Hit "Next>>" twice to get to data selection
3. "Select Address List..." and select ODS spreadsheet containing 2000 row recipient list
4. Uncheck address block option
5. Hit "Next>>"
6. Uncheck salutation option
7. Hit "Finish"
8. In the tool bar that appears under the formatting tool bar, select "Save Merged Documents"
9. Select "Save As Individual Documents"
10. Click "Save Documents"
11. Once document creation is complete specify save location
LibreOffice begins saving the documents, while doing so WindowServer memory usage increases, and part way through computer exits to operating system login screen.
Saved the 2000 merged documents to individual files in the specified location.
User Profile Reset: No
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
@Allen : whilst I agree that LO should be able to handle 2000 mail merge records without causing a session crash, could you please provide is with a minimum sample test ODB and sample ODT document with which to test, and detailed steps, otherwise, we are just guessing at what you might be merging.
What is the minimum number of records to cause the session to log out ?
What happens say, if you only merge 500 records ?
What happens if you only merge 1 field with 2000 records ? Does it still work, or does it fail ?
Setting to NEEDINFO pending requested information. Please set back to unconfirmed once you have provided this information.
I've attached a sample ODT file and ODS data source.
Regarding the follow up questions:
1) It depends based on how full my memory is, but between 600 and 800 was sufficient every time I tried to replicate the problem.
2) I was not able to replicate the problem with less than 500 records, in that the user session did not crash. However, the memory usage of WindowServer did still greatly increase.
3) I tried merging only one field with 1913 records and the session still crashed.
Created attachment 132549 [details]
Sample Address Data
Created attachment 132550 [details]
So no session crash for me with :
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
Threads CPU : 2; Version de l'OS :Mac OS X 10.12.4; UI Render : par défaut; Moteur de mise en page : nouveau;
Locale : fr-FR (fr_FR.UTF-8); Calc: group
however, I can confirm that while preparing the merge, WindowServer memory usage increases steadily to about 5Gb, then when saving to disk, the WindowServer memory usage maxed out at about 10Gb.
I have filed defect 107761 that is similar however mine involves Calc, not Writer. Not sure if these are related but I figure we can merge later if they they share the same cause\resolution.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Quote from Tor Lillqvist, bug 111893 comment 8 (with some info)
There are surely more serious leaks in our Mac code. The most obvious one is what causes a large number of backing store pixmaps to be repeatedly allocated when running some cppunit unit tests, which causes the WindowServer process to grow to tens of gigabytes for me. (It goes back to normal size as soon as the cppunit process in question exits.) This leak is as such caused by system code, but surely the root cause is that our code calls the system APIs in some peculiar way that one is not supposed to do. I am not sure if this leak also affects running LibreOffice itself, though, so as long as you are careful when running 'make check', and don't use any parallelism, I have nowadays managed to do it without crashing the whole machine because of lack of swap space or something..
Confirmed still present in LO 184.108.40.206
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default;
Locale: en-US (en_US.UTF-8); Calc: group threaded
Also, confirmed present in LO 3.3.0.