Bug 113566 - Memory for the copying part isn't released automatically when copying a dataset first and cutting it afterward (it has to be trigger by some event)
Summary: Memory for the copying part isn't released automatically when copying a datas...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks:
 
Reported: 2017-11-01 11:28 UTC by Telesto
Modified: 2018-09-03 16:31 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Screencast LibO6 (1.72 MB, video/mp4)
2017-11-01 12:31 UTC, Telesto 		Details
Screencast LibO4500 (1.36 MB, video/mp4)
2017-11-01 12:32 UTC, Telesto 		Details
Bibisect log (3.50 KB, text/plain)
2017-11-01 16:27 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-11-01 11:28:03 UTC 
Description:
Memory isn't released (for the copying part) when copying columns first followed by cutting 

Steps to Reproduce:
1. Open the file found here: https://yadi.sk/i/rM9QctDym5y3M
2. Copy Columns A-C
3. Cut columns A-C
4. Undo cut (CTRL+Z)
5. Copy A1 -> Clearing the memory back to initial. The first bump caused by copying copying A-C isn't released. 


Actual Results:  
The memory used for the first copy action isn't released. 


Expected Results:
Should be released


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.0.0.0.alpha1+
Build ID: 13c5dd1d98a480cb01ca8f24242c80e326e4ade8
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-10-30_23:52:07
Locale: nl-NL (nl_NL); Calc: CL

and in
Version: 5.1.0.1.0+
Build ID: 5616d22b57a9a5e57d545e912e029162a230829b
Threads 4; Ver: Windows 6.29; Render: default; 

but not in
Version: 4.5.0.0.alpha0+
Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
Locale: nl_NL

but broken again in
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 Eike Rathke 2017-11-01 12:12:53 UTC 
Copying A1 in the last step should not "clear the memory to initial". The Undo action for Cut is still in the Undo stack for Redo and Repeat.
Comment 2 Telesto 2017-11-01 12:31:15 UTC 
Created attachment 137416 [details]
Screencast LibO6

(In reply to Eike Rathke from comment #1)
> Copying A1 in the last step should not "clear the memory to initial". The
> Undo action for Cut is still in the Undo stack for Redo and Repeat.

That is not what I intended to say. I don't expect it to back to the initial state. I expect a memory usage of 390MB at the end of the steps (as with 5.0.0.5) instead of 550 MB (with LibO6)
Comment 3 Telesto 2017-11-01 12:32:02 UTC 
Created attachment 137417 [details]
Screencast LibO4500
Comment 4 Telesto 2017-11-01 16:27:24 UTC 
Created attachment 137423 [details]
Bibisect log

Bibisected to a range.. Most likely:

author	Kohei Yoshida <kohei.yoshida@collabora.com>	2014-11-25 05:02:21 (GMT)
committer	Kohei Yoshida <kohei.yoshida@collabora.com>	2014-11-25 15:00:14 (GMT)
commit 0dae7466fff1e742543ef7512b7dd22472c75624 (patch)
tree c9f146abd01a7cabd81944fd794c133cdecadca3
parent 8c041824b67caa53d3f7f96803b7a69ced6614b5 (diff)
Adjust ref undo to ensure group area listeners are used.
When undoing row deletion (and possibly other similar undo's).  And
write test for it.
Comment 5 Telesto 2017-11-01 17:26:41 UTC 
Hmm, changing my initial report a bit. The memory management is working fine. The only issue is with the timing/trigger needed before the release takes place..

1. Open the file found here: https://yadi.sk/i/rM9QctDym5y3M
2. Copy Columns A-C
3. Cut columns A-C
4. Undo cut (CTRL+Z)
5. Copy A1
6. Wait 20 seconds -> some drop, memory usage still high
7. Type something into E1
8. Copy E1 -> Memory usage will fall back to 390 MB

The memory bump at step 2 isn't released automatically after the 'cut'. It isn't triggered after copy (step 5) either. However, the memory usage starts reducing after typing something in cell E1 and copying it.
Comment 6 Buovjaga 2017-11-02 16:29:47 UTC 
(In reply to Telesto from comment #5)
> 8. Copy E1 -> Memory usage will fall back to 390 MB

It only falls to about 494 MB after waiting some tens of seconds.

Version: 6.0.0.0.alpha1+ (x64)
Build ID: 7e03c4eed72452fdfb87341214a21956c08ba969
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-10-26_00:58:29
Locale: fi-FI (fi_FI); Calc: group
Comment 7 Xisco Faulí 2018-01-15 11:22:35 UTC 
Hi Telesto,
Does the commit bisected in comment 4 applies to the steps in comment 5 or is it a different issue?
Comment 8 QA Administrators 2018-07-31 09:38:32 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2018-09-03 14:56:16 UTC Comment hidden (obsolete)
Comment 10 Telesto 2018-09-03 16:31:41 UTC 
1. Open the file found here: https://yadi.sk/i/rM9QctDym5y3M
2. Copy Columns A-C
3. Cut columns A-C
4. Undo cut (CTRL+Z)
5. Copy A1 -> Clearing the memory back to initial (has no effect)
6. Paste it somewhere (memory usage drops back to initial state)

The need for step 6 isn't perfect, but but everything else is fine, so.. WFM

Version: 6.2.0.0.alpha0+
Build ID: 22f2d8c41aa0a0a4cfa215c07ec06ae38cde7da8
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-08-29_04:32:58
Locale: nl-NL (nl_NL); Calc: CL