Bug 111893 - initNSApp() leaks memory
Summary: initNSApp() leaks memory
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha0+
Hardware: x86-64 (AMD64) macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-18 07:30 UTC by Alex Thurgood
Modified: 2018-05-18 09:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2017-08-18 07:30:18 UTC
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
Comment 1 Alex Thurgood 2017-08-18 07:31:34 UTC
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
Comment 2 Alex Thurgood 2017-08-18 07:32:08 UTC
#	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
Comment 3 Telesto 2017-08-18 12:22:11 UTC
Repro with: 5.4.0.3
Comment 4 Julien Nabet 2017-08-22 20:10:41 UTC
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
Comment 5 Julien Nabet 2017-08-22 20:36:15 UTC
Some interesting comments in tdf#103690 about vcl init and MacOs specifics (eg https://bugs.documentfoundation.org/show_bug.cgi?id=103690#c21)
Comment 6 How can I remove my account? 2018-05-17 12:57:53 UTC
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.
Comment 7 Alex Thurgood 2018-05-18 07:34:20 UTC
(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.
Comment 8 How can I remove my account? 2018-05-18 09:21:22 UTC
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...