Summary: | Calc leaks RAM in response to any action | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Allen Belletti <allen> |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | allen, guibomacdev, himajin100000, kemaldonado, telesto |
Priority: | medium | ||
Version: | 7.6.4.1 release | ||
Hardware: | ARM | ||
OS: | macOS (All) | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=159529 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: |
Description
Allen Belletti
2023-12-28 21:42:04 UTC
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 |