I'm currently using the latest 7.6.4.1 Apple Silicon release of LibreOffice Calc on a Mac M1 Mini 16GB. It's kept up to date and currently running MacOS Sonoma 14.2.1. That said, I've been experiencing what appears to be the same issue for quite some time before realizing what was happening. In short, Calc leaks vast amounts of memory during normal use until finally at ~9GB or so, it is running too slowly to use. At that point, I can save my work, close (which takes minutes) or Force Kill Calc, and then start over. No data is lost, but it's bizarre. Initially I thought this was related to a particular document in which I was often working. After more testing, it turns out that any document will behave the same way. Even a fresh, empty Calc document on a freshly-started copy of LO will exhibit the issue. I can reproduce as follows: 1. Start LibreOffice 2. Under "Create:" on the left-hand menu, select "Calc Spreadsheet" At this point, Activity Monitor shows 362.0 MB "Memory", 296.3 MB "Real Mem", 108.0 MB "Private Mem", and 77.7MB "Shared Mem". The numbers are stable as the application sits, open on a blank sheet "Untitled 1". 3. Click on random cells in the empty document. Not moving around via scroll bars, not typing anything, just selecting one cell and then another and another. Not groups or anything, just moving the pointer and left-clicking. I've now clicked about 50 times and see the following stabilized memory numbers in Activity Monitor: 1005.0 MB "Memory", 956.0 MB "Real Mem", 750.3 MB "Private Mem", 77.7 MB "Shared Mem". Once again these numbers are stable now that I'm no longer clicking. Once I start clicking again, the memory footprint resumes growing. In the case of doing real work in a document, Calc will eventually become very slow and ultimately unusable, after which the cycle above begins again. A few things worth mentioning: 1. Writer does not exhibit any strange behavior. 2. No other application on the Mac (and I use it constantly) behaves strangely. 3. I do have Homebrew installed w/ various dev tools and whatnot. 4. I'm completely aware that this sounds crazy, and that it's surely tied to something about my environment, but I haven't been able to identify it. Am hoping perhaps there are diagnostics and logging that I can run to provide you with additional information. It does seem to be a bug in Calc though, despite being triggered by some unique(?) conditions.
FWIW: a nasty bug slipped through into 7.6.4.1 which could be -indirectly - responsible for the leaking. You might try 24.2.0.0.beta1 to (double) check if the issue is still occurring https://dev-builds.libreoffice.org/pre-releases/mac/aarch64/LibreOfficeDev_24.2.0.0.beta1_MacOS_aarch64.dmg
I installed and tested the development version just now, but it behaves essentially the same. As soon as I've selected a new Calc document, I'm able to leak memory at will. However, I did notice a few additional details which I've confirmed back in 7.6.4.1 as well: 1. It's not actually necessary to click -- merely "swirling" the pointer around in circles will trigger the same memory leakage, but *only* when the pointer is over the Calc window. Making the same movements over the desktop or another application have the expected result (no effect). 2. If I carefully confine the pointer to moving only along the horizontal scroll bar (immediately beneath the visible cells) or vertical scroll back (immediately to the right of visible cells), memory does not leak. Perhaps because these are being redrawn by the window manager rather than the Calc app itself?
I just wanted to drop in here and mention that this bug (if others can confirm) does seem to only be on the ARM builds for macOS. I was not able to replicate on x86_64. Here is my info: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 12; OS: Mac OS X 14.2.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
@Patrick You might be interested in this one.
I'd been meaning to try the Mac/Intel build and @kdub inspired me to do so. TBH, I really expected the issue to disappear but it did not. As far as I can tell, it's behaving identically to the Apple Silicon build. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Mac OS X 14.2.1; UI render: Skia/Raster; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Mine appears identical to @kdub's except that he's using a better Mac ;-) Still looks like something about my environment must be triggering the behavior.
> Mine appears identical to @kdub's except that he's using a better Mac ;-) > > Still looks like something about my environment must be triggering the > behavior. Lol, yes, our Macs are almost identical. Honestly, this is probably pretty obvious, but I would look into anything that captures mouse input. For example, do you have a mouse settings program running in the background or something similar?
It turns out that @kdub is absolutely correct. I use a Logitech Marble Mouse (the trackball) and in order to enable quick scrolling, I've been running a little tool called "Smart Scroll" (https://www.marcmoini.com/sx_en.html) for years. Long enough to mostly forget it's there. Smart Scroll has 7 main functions (with many options under each.) Two of them, "Hover Scroll" and "Auto Scroll" seem to trigger this behavior merely by being enabled. The rest do not, as far as I can tell. Fortunately I'm only using "Grab Scroll" which can be enabled with no harmful effects. For my situation, this constitutes a fix. I've exercised Calc a considerable amount over the last couple of days and memory usage stays where it ought. ~230MB in the case of my most important document. Granted, Visicalc ran in 48K but it was hardly feature complete by modern standards. ;-) I'm going to reach out to the author of Smart Scroll and let him know what I've found. Perhaps the fact that it shows up with two specific features but not others will provide some sort of hint as to what's happening. Meanwhile, this does feel a bit like a "double bug", ie, a bug in Smart Scroll triggering another in Calc. I say that only because none of my other apps (including LibreOffice Writer) have this reaction to Smart Scroll. On the other hand, I'm not a front-end guy at all so this is pure speculation. I'll understand if this is promptly closed. Thanks for your time & attention! Cheers, Allen
Talked to the Smart Scroll author a bit. He mentioned that the tool sends "Accessibility requests [...] in order to find out if the mouse cursor is over an edge of a scrollable area." He also says that they're sent as infrequently as possible, "typically only while the cursor is moving." That matches what we're seeing here, as memory is only leaked when moving the cursor and even then, only over most of the Calc window (per the last paragraph of my Comment #2 here). It does sound like Calc is somehow leaking memory while handling these requests, since the leak does not show up in any other application, even within LibreOffice. It's probably not a code path that sees heavy use in "normal" circumstances. Fortunately for me, I'm able to turn off the features of Smart Scroll which trigger the bug while still retaining the features that I need. So for my personal situation, that's a 100% workaround. Feel free to close this, or let it lie until someone else runs into something similar. Of course, if some ambitious soul does want to investigate, I'm happy to run a debug version or otherwise help out with testing, replication, and data-gathering. Appreciate the interest on what's really a very obscure situation! Cheers, Allen