[Libreoffice-bugs] [Bug 111634] New: Multiple memory leaks in libmacabdrv1

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Thu Aug 10 09:53:14 UTC 2017


https://bugs.documentfoundation.org/show_bug.cgi?id=111634

            Bug ID: 111634
           Summary: Multiple memory leaks in libmacabdrv1
           Product: LibreOffice
           Version: 6.0.0.0.alpha0+ Master
          Hardware: x86-64 (AMD64)
                OS: Mac OS X (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Base
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: iplaw67 at tuta.io

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170810/a88c06a5/attachment-0001.html>


More information about the Libreoffice-bugs mailing list