After opening LibreOffice, the WindowServer process memory usage is typically around 400-500 MB. After 1-3 days using Calc, the memory will slowly rise to beyond 10GB thereby slowing down much of the graphics response, desktop changes, etc. Application response time is also affected presumably due to the graphics engine being tied up managing the WindowServer. No crash or error messages are observed. However, there is one log message that persists: ▼▼▼ LOG MESSAGE ▼▼▼ 5/9/17 10:25:14.354 PM WindowServer[145]: [cps/setfront] Failed setting the front application to LibreOffice, psn 0x0-0x39a69a3, securitySessionID=0x186a4, err=-13066 ▲▲▲ LOG MESSAGE ▲▲▲ Also, I know there is another WindowServer memory leak defect (107021) however that involves the Writer component performing a mail merge while my defect involves Calc and performing nothing terribly spectactular - just working with relatively small spreadsheets (2-3 open concurrently) with no more than 6 sheets per spreadsheet. While the earliest version observed to 5.0.0.2, I also tested this in 5.2.7.2 and the issue persists.
Unfortunately, LO leaks memory on macOS, even at startup, see for example bug 99929, and also the other bug you already found for Writer. You mention "after 1-3 days using Calc" - do you mean that you don't shut down LO in between opening/editing/closing files ? I ask this because we need to have a reproducible scenario. At present, if I open, edit and close a spreadsheet document, I can't reproduce the issue, so there is clearly something else, hence my question. Please also provide the version of MacOS that you are using. It would also be useful to have a sample spreadsheet, as we don't currently know which, if any, of the features of Calc you are using that might trigger this behaviour (e.g. automatically recalculated formulae, conditional formatting, charts, embedded drawings, etc). "Working with relatively small spreadsheets" simply isn't enough information for us to know how to reproduce the problem. Setting to NEEDINFO pending requested information.
There have already been many reports on the users lists in the past (unfortunately not in the bugzilla, methinks) of LO consuming all resources when left running over several days.
I will setup a dedicated test machine to reproduce the issue. Once I have been able to reliably reproduce on the test harness, I will provide the details of that environment along with a System Report.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20171204
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180102
Quote from Bug 116511 comment 10 (...) Anyway, I think that optimization is questionable, especially as the exact semantics of our horrible event loop API, like Application::AnyInput(), is under-defined and probably can and will change in various minor ways when people work on improving it on the Mac (and perhaps other platforms, too). (The event loop etc certainly needs improvement on the Mac, the "WindowServer grows to tens of gigabytes when running make check" issue is related. Unfortunately nobody has come up with a simple fix for that yet, exactly because we use our event loop related APIs in so imaginative ways all over the code, and fixing one thing breaks another.) (...)