Bug 112292 - Memory usage is steadily increasing every time when copying something to the clipboard even with 0 undo steps
Summary: Memory usage is steadily increasing every time when copying something to the ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.3 target:6.0.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2017-09-08 13:32 UTC by Telesto
Modified: 2017-10-15 21:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Attachments
Example file (40.92 KB, application/vnd.oasis.opendocument.text)
2017-09-08 13:59 UTC, Telesto 		Details
Bibisect log (2.51 KB, text/plain)
2017-10-04 09:42 UTC, Telesto 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2017-09-08 13:32:46 UTC 
Description:
Memory usage is steadily increasing every time when copying something to the clipboard

Steps to Reproduce:
1. Open the attached file (with zero undo steps)
2. Select All (CTRL+A)
3. Copy (CTRL+C) multiple times (12x) while monitor the memory usage -> increasing
4. Close the Writer document -> nearly no effect on the memory usage
5. Open a New writer document. Clear the clipboard -> type something into it; select it & copy it (still no substantial change)

Actual Results:  
Memory is steadily increasing

Expected Results:
No or a little increase


Reproducible: Always

User Profile Reset: No

Additional Info:
Repro with: 
Version: 6.0.0.0.alpha0+
Build ID: fc61be93c60967bf1d6bcffcada8189016d4530e
CPU threads: 4; OS: Windows 6.29; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-09-04_23:40:52
Locale: nl-NL (nl_NL); Calc: CL

but not with:
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Comment 1 Telesto 2017-09-08 13:59:00 UTC 
Created attachment 136121 [details]
Example file
Comment 2 Buovjaga 2017-09-08 14:06:42 UTC 
(In reply to Telesto from comment #0)
> 1. Open the attached file (with zero undo steps)

For zero undo steps: Open Tools - Options - LibO - Advanced - Expert config:
org.openoffice.Office.Common/Undo (and set it to 0)

I could repro this earlier in our private discussion, so setting to NEW
Comment 3 Telesto 2017-09-08 14:13:20 UTC 
Also found in:
Version: 5.4.0.3
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 4; OS: Windows 6.2; UI render: GL; 
Locale: nl-NL (nl_NL); Calc: CL

but not in:
Versie: 5.3.3.1 
Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout-Engine: nieuw; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 4 Telesto 2017-09-28 14:02:25 UTC Comment hidden (obsolete)
Comment 5 Telesto 2017-10-04 09:42:47 UTC 
Created attachment 136752 [details]
Bibisect log

demo@demo-VirtualBox:~/bibisect-linux-64-5.4$ ./instdir/program/soffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
demo@demo-VirtualBox:~/bibisect-linux-64-5.4$ git bisect good 06dcab7405b594a2914dae8558f189dbe76c267d is the first bad commit
commit 06dcab7405b594a2914dae8558f189dbe76c267d
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Feb 15 02:35:56 2017 +0100

    source sha:a754294ac7a902fe96fbbd6b8b6824a360d6b248
    
    source sha:a754294ac7a902fe96fbbd6b8b6824a360d6b248

:040000 040000 31cbaa8b68e7555ef20365f6cc8f557ef4bed34d a7568904504e5e5cb1d7790ad0e566732fb3baa9 M    instdir

----- 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=a754294ac7a902fe96fbbd6b8b6824a360d6b248

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-01-19 09:29:32 (GMT)
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-01-19 11:06:47 (GMT)
commit a754294ac7a902fe96fbbd6b8b6824a360d6b248 (patch)
tree 23ead80aa960366395713f2e4d032d9ca868d9a0
parent 071c74dfe24940b4222ed9576e2357d012b86617 (diff)
use rtl::Reference in SwDocFac
instead of manual acquire/release

Change-Id: I40b4f6d2893fe0d4113032f638bce1793fc47cd7
Comment 6 Telesto 2017-10-04 09:45:40 UTC 
Adding Cc: to Noel Grandin
Comment 7 Commit Notification 2017-10-04 12:19:01 UTC 
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=23f9a6c6c311725ec1b42a1ff4442023a0355ec0&h=libreoffice-5-4

tdf#112292: Revert "use rtl::Reference in SwDocFac"

It will be available in 5.4.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2017-10-05 11:50:43 UTC 
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cc483d0470dbf0d01e4da818b148ff0b851c5187

tdf#112292 - fix memory leak and use more auto ref counting in sw

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Telesto 2017-10-07 18:42:29 UTC 
No repro with:
Version: 6.0.0.0.alpha0+
Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25
Locale: nl-NL (nl_NL); Calc: CL

Thanks Noel!!
Comment 10 Telesto 2017-10-08 14:12:44 UTC 
@Noel
Is possible to use more 'auto ref counting' for Calc too? I can't reproduce the same memory build up as with Writer (memory will be released). But the the memory release seems to be sub-optimal, because it's pretty slow (but working in the end). So it's possible to hit a OOM, because the memory release is lagging behind.

1. Download and open https://yadi.sk/i/rM9QctDym5y3M (bug 96341)

2. Select column A, B & C
3. Hold CTRL+C for a while (10/15 times
4. Notice the increase in memory
5. Select cell A1 (clearing the memory) (Drop 1)
6. Wait a while, notice that Calc is clearing out memory
7. Close the document.. The memory usage will drop eventually to 113 MB or something like that on a x86 build)
Comment 11 Noel Grandin 2017-10-09 19:14:11 UTC 
sorry no, that sounds like something else
Comment 12 Buovjaga 2017-10-15 21:14:36 UTC 
(In reply to Telesto from comment #9)
> No repro with:
> Version: 6.0.0.0.alpha0+
> Build ID: c5a93cad149618bbd43632f1660a558c34bdbf7e
> CPU threads: 4; OS: Windows 6.3; UI render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2017-10-07_01:04:25
> Locale: nl-NL (nl_NL); Calc: CL
> 
> Thanks Noel!!

Let's set to FIXED, then.