Bug 107021 - WindowServer memory leak when performing mail merge in Writer
Summary: WindowServer memory leak when performing mail merge in Writer
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Mail-Merge Memory
  Show dependency treegraph
 
Reported: 2017-04-07 19:35 UTC by allen
Modified: 2023-01-13 03:20 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample Address Data (174.93 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-04-13 22:46 UTC, allen
Details
Sample Letter (21.16 KB, application/vnd.oasis.opendocument.text)
2017-04-13 22:47 UTC, allen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description allen 2017-04-07 19:35:58 UTC
Description:
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

Actual Results:  
LibreOffice begins saving the documents, while doing so WindowServer memory usage increases, and part way through computer exits to operating system login screen.

Expected Results:
Saved the 2000 merged documents to individual files in the specified location.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Alex Thurgood 2017-04-10 09:03:39 UTC
@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.
Comment 2 allen 2017-04-13 22:43:50 UTC
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.
Comment 3 allen 2017-04-13 22:46:35 UTC
Created attachment 132549 [details]
Sample Address Data
Comment 4 allen 2017-04-13 22:47:17 UTC
Created attachment 132550 [details]
Sample Letter
Comment 5 Alex Thurgood 2017-04-24 09:53:37 UTC
So no session crash for me with :

Version: 5.3.2.2
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.


Confirming
Comment 6 dev 2017-05-10 20:12:19 UTC
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.
Comment 7 QA Administrators 2018-05-11 02:33:24 UTC Comment hidden (obsolete)
Comment 8 Telesto 2018-06-25 17:42:17 UTC
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..
Comment 9 allen 2019-01-12 05:53:43 UTC
Confirmed still present in LO 6.1.3.2

Version: 6.1.3.2
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.
Comment 10 QA Administrators 2021-01-12 03:50:21 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2023-01-13 03:20:41 UTC
Dear allen,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug