CEF Crash on exit on OSX

[GoogleCodeExporter]

Observed in CEF 2171.1880 (and in 3.2062.1831).
We are observing a crash on exit with cef, with a "busted" auto release pool. 
Either if we call CefTerminate, or if we simply let the application exit 
without calling that API.

Example of crash stack is:
    #0  0x00007fff888f21da in _objc_trap() ()
    #1  0x00007fff888f231a in _objc_fatal ()
    #2  0x00007fff88900e3a in (anonymous namespace)::AutoreleasePoolPage::busted(bool) ()
    #3  0x00007fff888e872b in (anonymous namespace)::AutoreleasePoolPage::pop(void*) ()
    #4  0x00007fff84766272 in _CFAutoreleasePoolPop ()
    #5  0x00007fff8f81f413 in -[NSAutoreleasePool release] ()

The problem is caused by Initialize in 
"chromium/src/content/app/content_main_runner.cc"
That method creates an auto-release pool on the heap in the following statement:
    autorelease_pool_.reset(new base::mac::ScopedNSAutoreleasePool());

There are two significant problems with this:
1) When you run CEF in offscreen-rendering (OSR) mode, then the autorelease 
pool is not released until you terminate CEF. In our test, where we use CEF for 
a few minutes this auto release pool has many thousands of objects at shutdown 
time. This constitutes a serious memory leak. Every time the cef auto release 
pool is the active (top most) auto-release pool, auto-released objects will 
stay alive until the application exits.

2) The implementation violates the stack nature of auto-release pools because 
there is no guarantee that the CEF auto-release pool is the top most pool when 
it is later released. If the cef autorelease pool is not at the top when it is 
released, then you may corrupt memory. An Example that illustrates this is:
        NSAutoreleasePool* p1 = [[NSAutoreleasePool alloc] init];
        NSAutoreleasePool* p2 = [[NSAutoreleasePool alloc] init];
        [p1 release];
        [p2 release];
    This will crash. Note that there are runtime dependencies on the memory corruption. The crash behavior depends on the objects that you auto release between creating and releasing the various pools.

Solution options in order of preference:

1) Remove "autorelease_pool_" and let the caller of initialize handle setting 
up a proper (stack based) auto-release pool
2) Remove "autorelease_pool_" and add a stack based autorelease to initialize:

    virtual int Initialize(const ContentMainParams& params) OVERRIDE {
#if defined(OS_MACOSX)
        base::mac::ScopedNSAutoreleasePool autoreleasePoolScope;
#endif
3) Augment CefSettings and ContentMainParams to allow the caller to opt-out of 
the auto-release pool. In CEF this would be documented as the recommended 
option for OSR use cases - I would personally recommend it for any use case, so 
maybe we would call it useLegacyOSXAutoreleasePool and default to false.

Original issue reported on code.google.com by jsba...@gmail.com on 20 Nov 2014 at 5:09

• Merged into: #1240

[GoogleCodeExporter]

How is your application structured? If both CefInitialize and CefShutdown are 
called from a single main() function as demonstrated by the CEF sample 
applications then the ScopedNSAutoreleasePool in content_main_runner.cc should 
behave as expected.

Original comment by magreenb...@gmail.com on 20 Nov 2014 at 5:14

[GoogleCodeExporter]

We use CEF as an embedded component and we own the message loop. We call 
CefDoMessageLoopWork and not CefRunMessageLoop.

Original comment by jsba...@gmail.com on 20 Nov 2014 at 5:21

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 20 Nov 2014 at 5:24

• Changed state: Duplicate

[GoogleCodeExporter]

The original description is a bit confusing (I apologize). Where we refer to 
OSR mode, we mean to refer to the fact that we own the message loop (using 
CefDoMessageLoopWork and not CefRunMessageLoop). The reference  to OSR is not 
related to this issue.

Original comment by jsba...@gmail.com on 20 Nov 2014 at 6:03

[GoogleCodeExporter]

I have created the following crbug for this: 
https://code.google.com/p/chromium/issues/detail?id=458596&thanks=458596&ts=1423
852316

Original comment by jsba...@gmail.com on 13 Feb 2015 at 6:32