Memory leak introduced in cc8ca5b6a5

[jbrianceau]

It is very likely that cc8ca5b introduced a memory leak.

The linux_chromium_asan_rel_ng Chromium try bot reports memory leaks with this commit (and next ones), whereas no leak is reported with its parent (and previous ones).

Example of leaking unit test : CdmAdapterTest.Initialize

See Chromium CL comments for further information

[pkasting]

You said you can reproduce this locally -- are you able to do so in a debug build that can dump allocation stacks with symbols? That might make it easier to track this down.

[jbrianceau]

Unfortunately, I cannot get a stack with symbols from my local environment, even in a debug build.

However I was able to make progress on this issue : current Chromium build of protobuf forces GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define (in BUILD.gn). If I remove this define, the leak goes away.

I was also able to narrow down the change causing the regression to src/google/protobuf/compiler/cpp/cpp_file.cc and/or src/google/protobuf/compiler/cpp/cpp_message.cc file(s) of cc8ca5b.

[jbrianceau]

So far, the best call stacks I can get look like this :

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x59a46b in operator new(unsigned long) (/local/host-chromium/build-asan/media_unittests+0x59a46b)
    #1 0x7fde7b29695f  (<unknown module>)
    #2 0x7fde7b296a09  (<unknown module>)
    #3 0x7fde7b29731e  (<unknown module>)
    #4 0x7fde7b295fa3  (<unknown module>)
    #5 0x7fde7b296a09  (<unknown module>)
    #6 0x7fde7b29731e  (<unknown module>)
    #7 0x7fde7b288c86  (<unknown module>)
    #8 0x7fde7b270911  (<unknown module>)
    #9 0x7fde7b296a09  (<unknown module>)
    #10 0x7fde7b29731e  (<unknown module>)
    #11 0x7fde7b270c7c  (<unknown module>)
    #12 0x7fde7b296a09  (<unknown module>)
    #13 0x7fde7b29731e  (<unknown module>)
    #14 0x7fde7aa2aef2  (<unknown module>)
    #15 0x7fde8b4e9109 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:78
    #16 0x7fde8b4e91f2 in call_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:36
    #17 0x7fde8b4e91f2 in _dl_init /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-init.c:126
    #18 0x7fde8b4edc2f in dl_open_worker /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-open.c:577
    #19 0x7fde8b4e8fc3 in _dl_catch_error /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-error.c:187
    #20 0x7fde8b4ed37a in _dl_open /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-open.c:661
    #21 0x7fde8b06602a in __asprintf /build/eglibc-oGUzwX/eglibc-2.19/dlfcn/dlopen.c:66
    #22 0x7fde8b4e8fc3 in _dl_catch_error /build/eglibc-oGUzwX/eglibc-2.19/elf/dl-error.c:187
    #23 0x7fde8b06662c in _dlerror_run /build/eglibc-oGUzwX/eglibc-2.19/dlfcn/dlerror.c:163
    #24 0x7fde8b0660c0 in dlopen /build/eglibc-oGUzwX/eglibc-2.19/dlfcn/dlopen.c:87
    #25 0x542009 in __interceptor_dlopen (/local/host-chromium/build-asan/media_unittests+0x542009)
    #26 0x178b7db in base::LoadNativeLibraryWithOptions(base::FilePath const&, base::NativeLibraryOptions const&, base::NativeLibraryLoadError*) /local/host-chromium/build-asan/../src/base/native_library_posix.cc:42:14
    #27 0x178b6db in base::LoadNativeLibrary(base::FilePath const&, base::NativeLibraryLoadError*) /local/host-chromium/build-asan/../src/base/native_library.cc:11:10
    #28 0x5fb650 in media::ExternalClearKeyTestHelper::LoadLibrary() /local/host-chromium/build-asan/../src/media/cdm/external_clear_key_test_helper.cc:46:18
    #29 0xba9048 in media::CdmAdapterTest::CdmAdapterTest() /local/host-chromium/build-asan/../src/media/cdm/cdm_adapter_unittest.cc:78:3
    #30 0xba88ca in CdmAdapterTest_Initialize_Test /local/host-chromium/build-asan/../src/media/cdm/cdm_adapter_unittest.cc:253:1
    #31 0xba88ca in testing::internal::TestFactoryImpl<media::CdmAdapterTest_Initialize_Test>::CreateTest() /local/host-chromium/build-asan/../src/testing/gtest/include/gtest/internal/gtest-internal.h:484

Where <unknown module> seems to be libclearkeycdm.so :

7fde7a262000-7fde7dff8000 r-xp 00000000 08:11 1276324       /local/host-chromium/build-asan/libclearkeycdm.so
7fde7dff8000-7fde7e1eb000 r--p 03d95000 08:11 1276324       /local/host-chromium/build-asan/libclearkeycdm.so
7fde7e1eb000-7fde7e552000 rw-p 03f88000 08:11 1276324       /local/host-chromium/build-asan/libclearkeycdm.so

[jbrianceau]

By comparing the generated code, I think the actual problem is that GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define logic has been inverted between 337a028 and cc8ca5b for c++ (at least).

As a matter of fact, the CdmAdapterTest.Initialize Chromium test :

• reports leaks using 337a028 without GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define
• doesn't report leaks using 337a028 with GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define
• reports leaks using cc8ca5b with GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define
• doesn't report leaks using cc8ca5b without GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER define

So the leak wouldn't be a leak per say, but just a detection of statically initialized objects that are not freed (as we could expect).

I'll try to work on a fix on monday