<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Multiple memory leaks in libmacabdrv1"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=111634">111634</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Multiple memory leaks in libmacabdrv1
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>6.0.0.0.alpha0+ Master
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Mac OS X (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Base
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>iplaw67@tuta.io
</td>
</tr></table>
<p>
<div>
<pre>Description:
Analysing memory leaks with Instruments.app on MacOS and my LibreOffice master
build indicates that there are multiple (literally 1000's) invocations of code
for mallocs which appear to be leaked. This might be the reason why accessing
the MacAb is so slow...
Steps to Reproduce:
1. Start XCode, then Instruments.app
2. Choose Memory Leak profile tool
3. Select LibreOffice.app in instdir as target process
4. Click on the record button, LODev is started by the profiling tool
5. Wait for the StartCenter to load.
6. Load a previously created MacAb.odb file
7. Click on Tables.
8. Double-click on the MacAb table to open it.
9. Close the table.
10. Close the ODB file.
9. Stop recording.
10. Analyse the profile trace.
Actual Results:
Multiple instances of memory leaks.
Expected Results:
It shouldn't leak memory.
Reproducible: Always
User Profile Reset: No
Additional Info:
The major leaks occur in :
macabrecord.cxx lines 68-80 (at least 10,072 iterations) :
void MacabRecord::insertAtColumn (CFTypeRef _value, ABPropertyType _type, const
sal_Int32 _column)
{
if(_column < size)
{
if(fields[_column] == nullptr)
fields[_column] = new macabfield;
fields[_column]->value = _value;
if (fields[_column]->value)
CFRetain(fields[_column]->value);
fields[_column]->type = _type;
}
}
with :
fields[_column] = new macabfield;
being singled out by the tool as the problematic instruction
Other "leaky" points :
lines 546-563 of macabrecords.cxx (3175 iterations)
and in particular line 560 : headerNames[0] = new macabfield;
lines 116-133 of macabrecords.cxx (multiple instances of ca. hundreds/thousands
of iterations)
and in particular line 124 : macabfield *_copy = new macabfield;
lines 857-892 of macabrecords.cxx
in particular
line 860 : MacabRecord *macabRecord = new MacabRecord(_header->getSize());
line 880 : propertyValue = ABRecordCopyValue(_abrecord,propertyName);
line 885 : insertPropertyIntoMacabRecord(propertyType, macabRecord, _header,
propertyNameString, propertyValue);
line 71 in macabutilities :
CFStringRef ref = CFStringCreateWithCharacters(kCFAllocatorDefault,
reinterpret_cast<UniChar const *>(aString.getStr()), aString.getLength());
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0)
Gecko/20100101 Firefox/54.0</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>