Description: initNSApp() leaks memory when LibreOffice is started. 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. Close the StartCenter window 7. Stop recording. 8. Analyse the profile trace. Actual Results: Memory leak due to incorrect ref count not releasing memory on closure. Expected Results: Should not leak memory Reproducible: Always User Profile Reset: No Additional Info: The code at issue is here lines 200-214 in salinst.cxx: initNSApp(); OUString aExeURL, aExe; osl_getExecutableFile( &aExeURL.pData ); osl_getSystemPathFromFileURL( aExeURL.pData, &aExe.pData ); OString aByteExe( OUStringToOString( aExe, osl_getThreadTextEncoding() ) ); #ifdef DEBUG aByteExe += OString ( " NSAccessibilityDebugLogLevel 1" ); const char* pArgv[] = { aByteExe.getStr(), NULL }; NSApplicationMain( 3, pArgv ); #else const char* pArgv[] = { aByteExe.getStr(), nullptr }; NSApplicationMain( 1, pArgv ); #endif with the leaks occurring in particular here : initNSApp(); and NSApplicationMain( 1, pArgv ); User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Ref count table : # Event Type ∆ RefCt RefCt Timestamp Responsible Library Responsible Caller 0 Malloc +1 1 00:01.597.450 libvcllo.dylib initNSApp() 1 Retain +1 2 00:01.597.466 Foundation -[NSThread initWithTarget:selector:object:] 2 Release -1 1 00:01.597.965 Foundation __NSFinalizeThreadData
# Event Type,∆ RefCt RefCt Timestamp Responsible Library Responsible Caller 0 Malloc,+1 1 00:01.597.450 libvcllo.dylib initNSApp() # Event Type,∆ RefCt RefCt Timestamp Responsible Library Responsible Caller 1 Retain,+1 2 00:01.597.466 Foundation -[NSThread initWithTarget:selector:object:] # Event Type,∆ RefCt RefCt Timestamp Responsible Library Responsible Caller 2 Release,-1 1 00:01.597.965 Foundation __NSFinalizeThreadData
Repro with: 5.4.0.3
I looked at initNSApp method and noticed that some observers were added (see https://opengrok.libreoffice.org/xref/core/vcl/osx/salinst.cxx#139) but never released. On MacOs I tried to follow the init process but I indeed never reached the end of Desktop::Main as announced with: 1700 // CAUTION: you do not necessarily get here e.g. on the Mac. (see https://opengrok.libreoffice.org/xref/core/desktop/source/app/app.cxx#1700) The weird thing is this other line: 1701 // please put all deinitialization code into doShutdown I can't reach doShutdown on my Mac so can't deinitialize properly. By adding some std::cerr, I noticed, LO went until DoExecute (line 1666) then nothing I tried to launch it with lldb but when quitting soffice, there's no abort, LO exits with return code 0 I'm a bit stuck here. Thorsten: I put you in cc as MacOs expert (from https://wiki.documentfoundation.org/FindTheExpert) but know that you're dealing with EMF/WMF part Stephan: having noticed you had fixed some MacOs specific pbs, thought you might be interested in this one
Some interesting comments in tdf#103690 about vcl init and MacOs specifics (eg https://bugs.documentfoundation.org/show_bug.cgi?id=103690#c21)
initNSApp is called just once, right? Then it is not a leak. A leak is when a resource (like memory) is allocated but not freed (even if unused afterwards) each time some code is executed, and the longer the program runs (or the more times you do some specific action), the more resources are allocated and left allocated even if not used.
(In reply to Tor Lillqvist from comment #6) > initNSApp is called just once, right? Then it is not a leak. A leak is when > a resource (like memory) is allocated but not freed (even if unused > afterwards) each time some code is executed, and the longer the program runs > (or the more times you do some specific action), the more resources are > allocated and left allocated even if not used. So let's close this as INVALID due to a false positive of the Instruments.app ? I'm not in a position to decide, I just ran the tool and it flagged this up, so I reported it.
Yeah, I think this can be closed. There are surely more serious leaks in our Mac code. The most obvious one is what causes a large number of backing store pixmaps to be repeatedly allocated when running some cppunit unit tests, which causes the WindowServer process to grow to tens of gigabytes for me. (It goes back to normal size as soon as the cppunit process in question exits.) This leak is as such caused by system code, but surely the root cause is that our code calls the system APIs in some peculiar way that one is not supposed to do. I am not sure if this leak also affects running LibreOffice itself, though, so as long as you are careful when running 'make check', and don't use any parallelism, I have nowadays managed to do it without crashing the whole machine because of lack of swap space or something...