<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:iplaw67@tuta.io" title="Alex Thurgood <iplaw67@tuta.io>"> <span class="fn">Alex Thurgood</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - MacOS: Memory isn't released to the initial state when closing a file after saving"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=119591">bug 119591</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>UNCONFIRMED
</td>
<td>NEW
</td>
</tr>
<tr>
<td style="text-align:right;">Ever confirmed</td>
<td>
</td>
<td>1
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - MacOS: Memory isn't released to the initial state when closing a file after saving"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=119591#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - MacOS: Memory isn't released to the initial state when closing a file after saving"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=119591">bug 119591</a>
from <span class="vcard"><a class="email" href="mailto:iplaw67@tuta.io" title="Alex Thurgood <iplaw67@tuta.io>"> <span class="fn">Alex Thurgood</span></a>
</span></b>
<pre>Hmm, my experimentation so far just shows LO consuming more and more memory to
the point where my system becomes unresponsive requiring a force kill of the LO
process.
I loaded LOdev master into Instruments.app and then followed memory allocations
(until both LO and Insruments became unresponsive).
Once the document is loaded, transient memory allocation is running at 10 Gb.
I made a single digit change to one value without a comment in one cell, and
then attempted a re-save.
Instruments shows that memory allocation goes through the roof, passing from
10Gb transient to 85Gb transient memory, at which point my whole system becomes
unresponsive. Both LO and Instruments grind to a halt.
The memory guzzlers in this seem to be a combination of:
- rtl_UString_new_WithLength : only 1.5kb each, but a gazillion of them
- rtl_Ustring_ImplAlloc(int) : quite a few of these too at 416 bytes a throw
This block is pointed to in strtmpl.cxx (1139-1157)
IMPL_RTL_STRINGDATA* IMPL_RTL_STRINGNAME( ImplAlloc )( sal_Int32 nLen )
{
IMPL_RTL_STRINGDATA * pData
= (sal::static_int_cast< sal_uInt32 >(nLen)
<= ((SAL_MAX_UINT32 - sizeof (IMPL_RTL_STRINGDATA))
/ sizeof (IMPL_RTL_STRCODE)))
? static_cast<IMPL_RTL_STRINGDATA *>(rtl_allocateString(
sizeof (IMPL_RTL_STRINGDATA) + nLen * sizeof (IMPL_RTL_STRCODE)))
: nullptr;
- I also see loads of calls to SfxItemSet::SfxItemSet(SfxItemSet const&),
allegedly from itemset.cxx, but a search in itemset.cxx doesn't return any such
line...</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>