Bug 93409 - Memory leak when setting cell value from a macro: EDITING
Summary: Memory leak when setting cell value from a macro: EDITING
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2015-08-13 12:40 UTC by Mikhail Zemlyanukha
Modified: 2025-01-12 17:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
crash popup message (80.19 KB, image/jpeg)
2015-08-13 12:40 UTC, Mikhail Zemlyanukha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Zemlyanukha 2015-08-13 12:40:06 UTC
Created attachment 117890 [details]
crash popup message

This bug was reported by my customer for LibO Calc 5.0.0.5 on MS Windows platform. 

I tested it in a daily build 5.1.0.0.alpha1+ Build ID: 9ef671364ff9fbb552a5433053af9283d12d90c7 on Linux platform, and it seems to be reproducible there as well. I saw increasing memory usage by soffice process, using 'ps' tool. My customer reports that LibO crashes when all memory goes away, reporting an com.sun.star.uno.RuntimeException, screen shot attached

I tested on Version: 4.4.5.2 Build ID: 4.4.5.2 Arch Linux build-1 and I do _not_ observe the issue there (ps command doesn't show that memory usage by soffice increases).

Steps to reproduce:

1. Launch LibO calc
2. create following macro:
Sub Main
  Sheet = thisComponent.Sheets("Sheet1")
  For i =0 to 10000000
      dann ="42202705"
      Sheet.getCellByPosition(0, 0).String = dann & "   i=" & i
  Next i
End Sub
3. run the macro
4. observe memory usage with 
ps -aef |grep soffice

in some time RAM goes out and LibO crashes
Comment 1 Mikhail Zemlyanukha 2015-08-13 12:41:56 UTC
These bugs may be related: #88006 #93392
Comment 2 Mikhail Zemlyanukha 2015-08-13 12:50:52 UTC
My customer says that the issue is _not_ reproducible in OpenOffice 4.1.1 on MS Windows
Comment 3 raal 2015-08-20 18:49:33 UTC
I can not confirm with Version: 5.1.0.0.alpha1+
Build ID: 6b7354ae66db40246a09e00aa876443057655a43
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-19_01:05:16

After ~3 hours of run macro ended without crash, "42202705   i=10000000"
Comment 4 raal 2015-08-20 18:59:53 UTC
But soffice takes 50% of memory (6GB of RAM)
Comment 5 Mikhail Zemlyanukha 2015-08-21 19:13:30 UTC
I didn't saw the crash on LibO 5.1 master branch either, just increasing memory usage.

Did you test with patch for https://bugs.documentfoundation.org/show_bug.cgi?id=93392 integrated? I feel it may fix the issue.
Comment 6 Mikhail Zemlyanukha 2015-08-21 19:30:02 UTC
Hm, I see from source code that the fix for #93392 does not affect current case, it's for HTML parsing.

And I tested against the latest /daily/master/Linux-rpm_deb-x86_64@70-TDF-dbg/2015-08-21_07.14.55 and it behavior remains the same.
Comment 7 QA Administrators 2016-09-20 10:26:00 UTC Comment hidden (obsolete)
Comment 8 Noel Grandin 2018-03-26 13:13:37 UTC
I can't reproduce this leak with current master on Linux.
Comment 9 Julien Nabet 2018-11-14 14:24:13 UTC
Mikhail/Raal: following Noel's comment, do you reproduce the memory leak with 6.1.3?
Comment 10 Mikhail Zemlyanukha 2018-11-14 15:18:58 UTC
Yes, the issue still reproduces in LibO 6.1.3.2 - running macro eats RAM indefinitely.
Comment 11 Mikhail Zemlyanukha 2018-11-14 15:38:10 UTC
Version: 6.1.3.2
Build ID: 6.1.3-1
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

From Arch Linux distro
Comment 12 QA Administrators 2021-01-11 03:57:57 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2023-01-12 03:21:18 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2025-01-12 03:13:30 UTC Comment hidden (obsolete)
Comment 15 Charles Williams 2025-01-12 17:44:22 UTC
Does not seem to be present on macOS

Version: 24.8.4.2 (AARCH64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 8; OS: macOS 15.2; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Real Memory Size reported by Activity Monitor:

Open LO no windows open: 1.15 GB
Create new spreadheet window: 1.19 GB
Create macro: 1.23 GB
Macro running: 1.30 GB (i=0)
Macro running: 1.25 GB (i=13000)
Macro running: 1.32 GB (i=30000)
Macro running:s: 1.27 GB (i=335000) [After 5 hours of running]

It does seem to me that the macro runs rather slowly but that is presumably because it updates the displayed value of the cell every time.