Which version of LO do you use?

Could it be something like this: https://bugs.documentfoundation.org/show_bug.cgi?id=151736 ?

If not: Please attach a Writer document here, which shows the buggy behavior for you.

Hardware: (PC)
Processor: 12th Gen Intel(R) Core(TM) i5-12400   2.50 GHz
Memory:12.0GB
Software:
Operating System: Windows 11 Home 22H2 22621.1265
LibreOffice Version: 7.3.7.2 (x64) / LibreOffice Community

1. In Windows 11, open task manager showing memory usage graph
2. Open LibreOffice Writer and a large file (doesn't have to be a large file, but it is easier/faster to duplicate with it - I think I have seen this with multiple smaller files open when cutting and pasting between files). My sample file is about 350 pages long with lots of text and is in Word .docx format. Opening the file does not cause memory usage to bump up very much. I decided to not include the sample file since it contained personal information. However, I have seen this with several different files. Also, my files are on a Sandisk SSD (2TB) connected via USB 3.0. Less than half the space on the SSD is used.
3. With File Manager visible (1/2 screen) and LibreOffice 1/2 screen (in order to monitor the memory usage), start scrolling through the file continuously. I have a trackball and use the scroll wheel.
4. Continue scrolling through the file. Note that the memory usage continues to increment as you scroll through the file. When the memory usage hits 94%, CPU usage jumps and LibreOffice freezes, then crashes and closes.
For me, this causes a crash of LibreOffice every time.
I have had similar crashes on my Linux Mint machine, but didn't know how to duplicate the problem. If desired, I can fire it up later and try to duplicate there, now knowing how to duplicate it.
I suspect that this memory leak (or perhaps there is a better term) is the root cause of several other bug reports. I am also fairly certain I experienced this same issue on previous versions of LibreOffice.
The "work around" is to save changes frequently.

Created attachment 185539 [details]
Multiple Copies of the US Constitution as a sample file to duplicate the bug

I was able to duplicate the bug with this file as described in my previous post. Open the file and continuously scroll through the file using the scroll wheel. In this case, the memory usage reached 96% before crashing. When the CPU usage spiked, I saw that Windows Problem Reporting program go to the top of the usage list. However, when I tried this a second time it did not crash. In order to get it to crash, I opened a second file and switched back and forth scrolling in each file. This is consistent with what I do in actual editing, cutting and pasting between files.

Tested the attached document with OpenSUSE 15.3 64bit rpm Linux. Couldn't reproduce growing of used memory. Is contant 2,8 GB (of 16 GB max.)
Tested with LO 7.3.6.2 and also LO 7.5.1.1

Might be it is a special Windows bug.

Apparently, as you suggested, this is a special Windows bug. I booted up my Linux Mint (20.3) machine (Dell Inspiron 3847 Intel Core i5-4460 with 12GB memory) and could not duplicate the issue. I went back to my windows machine and with the same original sample file and a copy of it I was able to duplicate it right away. The key seemed to be having TWO files open at the same time and then scrolling through one of the files. I might start to spend more time with my Linux machine. :)

I can back up that I'm having this issue as well, with LibreOffice 7.5.0 and also 7.4.5, running on my Windows 10 laptop.
Steps to reproduce:
1. Open LibreOffice and put a bunch of text into it, or open a preexisting file. The file can be less than one page in length, but the bigger the document, the faster the RAM buildup.
2. Select some text. The more text you select, the more RAM you'll eat up in step 3.
3. Start scrolling up and down in the document. As you scroll, the RAM usage of LibreOffice will increase. Deselecting text does not reduce the amount of RAM used.
4. Eventually, the computer will run out of memory and Windows will start to kill applications.

Running LibreOffice in safe mode will fix the issue completely, but if I reset to factory settings and run LibreOffice normally, the issue returns.


Note: In a sufficiently complex document (perhaps related to embedded images, IDK) LibreOffice will leak memory just from scrolling around, and selecting text will just make the memory leak happen faster. For example, in a 7 page document with multiple images, form sections, etc, LibreOffice Writer in Safe Mode doesn't ever breach 250 MB of RAM usage, but without Safe Mode, scrolling to the bottom of the document (after selecting all text with Ctrl+A) pushes RAM usage over 3.1 GB. Scrolling back to the top increases that number to 4.46 GB!

Please bump this bug from "normal" to "major". It causes LibreOffice to crash and sometimes Windows decides to close other applications as well. I have to either (a) keep Windows Task Manager on my screen to closely monitor my RAM usage, or (b) run LibreOffice Writer in Safe Mode for everything.


Version: 7.4.5.1 (x64) / LibreOffice Community
Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

I just installed 7.4.6 and can confirm that the memory leak is still unfixed.

We don't know if the three issues described here are related.

nagyhadnagy, James: Please copy and paste here the contents of your Help - About (LibreOffice - About on macOS) by clicking the copy button. This allows us to know more about your system.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

Wolf Icefang: I see you use Vulkan. Does it make a difference, if you deactivate it from Tools - Options (LibreOffice - Preferences on macOS) - LibreOffice - View - Use Skia for all rendering?

I scrolled through the entire attachment 185539 [details] with page down and reached 158MB memory used. So nothing bad happened. Scrolling with mouse wheel increased it more quickly, but still nothing special

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 002f941ec20e594e9702c39fab9cf9f4cc392dab
CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_FI); UI: en-US
Calc: threaded

Good news! Turning off "Use Skia for all rendering" fixed the issue for me. Thank you!

Version: 7.4.6.2 (x64) / LibreOffice Community
Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

(In reply to Wolf Icefang from comment #9)
> Good news! Turning off "Use Skia for all rendering" fixed the issue for me.
> Thank you!
> 
> Version: 7.4.6.2 (x64) / LibreOffice Community
> Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d
> CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
> Locale: en-US (en_US); UI: en-US
> Calc: CL

So let us set this one to WORKSFORME

Back to needinfo as we have three people here. Besides, it's not okay for Skia to cause such an issue.

1. Turning off SKIA on my Windows 11 machine does "fix" the problem.
2. I notice that on my Linux Mint machine LibreOffice does not have a checkbox for SKIA. I could not duplicate this problem on my Linux machine.
3. Previously, I had a similar problem for which the "fix" was to uncheck the anti-aliasing checkbox. So I have been running my Windows 11 machine with the anti-aliasing checkbox unchecked.

Thanks for testing. I'll set this to NEW while assuming nagyhadnagy's issue is also related to Skia as it is not seen in Safe Mode.