MACOS: Small memory leaks when discarding document recovery
Steps to Reproduce:
1. Open Writer with multiple (empty) documents
2. Force quite
3. Start the Instruments
4. Choose Memory Leak profile tool
5. Select LibreOffice.app in instdir as target process
6. Click on the record button, LODev is started by the profiling tool
7. Discard the document recovery (and don't save any recovery file)
User Profile Reset: No
Build ID: d46dc8e547810208287aab77f0313f1971901464
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default;
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-12-08_10:35:46
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8
Created attachment 138437 [details]
Small addition. I'm rather often noticing small leaks (as in this case) when interacting with the GUI:
CGEvent SkyLight SLTypeCreateInstance
_NSLocalEventObserver NSEvent ddLocalMonitorForEventsMatchingMask:placement:handler:]
I haven't reported them separately, because the responsible library comes from Apple... Or can this be fixed in the LibreOffice code?
(In reply to Telesto from comment #2)
> Small addition. I'm rather often noticing small leaks (as in this case) when
> interacting with the GUI:
> CGEvent SkyLight SLTypeCreateInstance
> _NSLocalEventObserver NSEvent
> I haven't reported them separately, because the responsible library comes
> from Apple... Or can this be fixed in the LibreOffice code?
Yes, I have noticed this too. If it is Apple's code, there probably isn't much we can do. When I tried hunting down some of these via Instruments to the source code, I just ended up in the assembler instructions, so there probably isn't anything we can do. If there is Apple code that we include for which the source is available (e.g. because we have included it in our git repo) then at least we could point out to Apple where the problem might lie, but if it just points to some assembler, I'm assuming we're not going to have access to any sort of other source code. Of course, someone competent enough in disassembly might be able to do something with it, but would that go against Apple's Developer T&Cs ?
Are the leaks originally reported still present in master?
Regarding the ones in comment 2, as Alex mentioned, probably there isn't much we can do...
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Created attachment 139332 [details]
A leaking backtrace with symbols
Build ID: d1bc14b318c9a412a761d243085da0895a1aed4a
CPU threads: 4; OS: Mac OS X 10.13.1; UI render: default;
Locale: nl-NL (nl_US.UTF-8); Calc: group threaded