Memory leak of `isc_attach_database`

[SakiTakamachi]

Hi,

The following code:

// fire.c
#include <ibase.h>
#include <string.h>
#include <stdio.h>

int main (void) {
    ISC_STATUS isc_status[20];
    isc_db_handle db;
    char *dpb = "/* your dpb */";
    short dpb_len = strlen(dpb);

    isc_attach_database(isc_status, 0,"/* your db name */", &db, dpb_len, dpb);
    isc_detach_database(isc_status, &db);
    
    return 0;
}

gcc -fsanitize=leak,undefined,address -fno-sanitize-recover -DZEND_TRACK_ARENA_ALLOC -Wall -o fire fire.c -lfbclient

execute:

# ./fire

=================================================================
==7619==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7f59687ac966 in mp_init (/lib/x86_64-linux-gnu/libtommath.so.1+0x7966)
    #2 0x7f596958e157  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcc157)
    #3 0x7f596958ccb9  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcacb9)
    #4 0x7f59695b6fff  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf4fff)
    #5 0x7f59695b538b  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf338b)
    #6 0x7f59695ba106  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf8106)
    #7 0x7f59695a1280  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdf280)
    #8 0x7f59695a1ab5  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdfab5)
    #9 0x7f59695b160a  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xef60a)
    #10 0x7f5969531fa7  (/lib/x86_64-linux-gnu/libfbclient.so.2+0x6ffa7)
    #11 0x7f5969532832 in isc_attach_database (/lib/x86_64-linux-gnu/libfbclient.so.2+0x70832)
    #12 0x5620c550e3a8 in main (/mount/fire+0x13a8)
    #13 0x7f5968987082 in __libc_start_main ../csu/libc-start.c:308

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7f59687ac966 in mp_init (/lib/x86_64-linux-gnu/libtommath.so.1+0x7966)
    #2 0x7f596958e143  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcc143)
    #3 0x7f596958ccb9  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcacb9)
    #4 0x7f59695b6fff  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf4fff)
    #5 0x7f59695b538b  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf338b)
    #6 0x7f59695ba106  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf8106)
    #7 0x7f59695a1280  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdf280)
    #8 0x7f59695a1ab5  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdfab5)
    #9 0x7f59695b160a  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xef60a)
    #10 0x7f5969531fa7  (/lib/x86_64-linux-gnu/libfbclient.so.2+0x6ffa7)
    #11 0x7f5969532832 in isc_attach_database (/lib/x86_64-linux-gnu/libfbclient.so.2+0x70832)
    #12 0x5620c550e3a8 in main (/mount/fire+0x13a8)
    #13 0x7f5968987082 in __libc_start_main ../csu/libc-start.c:308

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794a06 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:153
    #1 0x7f59687ac966 in mp_init (/lib/x86_64-linux-gnu/libtommath.so.1+0x7966)
    #2 0x7f596958e12f  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcc12f)
    #3 0x7f596958ccb9  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xcacb9)
    #4 0x7f59695b6fff  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf4fff)
    #5 0x7f59695b538b  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf338b)
    #6 0x7f59695ba106  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xf8106)
    #7 0x7f59695a1280  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdf280)
    #8 0x7f59695a1ab5  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xdfab5)
    #9 0x7f59695b160a  (/lib/x86_64-linux-gnu/libfbclient.so.2+0xef60a)
    #10 0x7f5969531fa7  (/lib/x86_64-linux-gnu/libfbclient.so.2+0x6ffa7)
    #11 0x7f5969532832 in isc_attach_database (/lib/x86_64-linux-gnu/libfbclient.so.2+0x70832)
    #12 0x5620c550e3a8 in main (/mount/fire+0x13a8)
    #13 0x7f5968987082 in __libc_start_main ../csu/libc-start.c:308

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f5968987914 in __GI___gconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/gconv_open.c:78
    #2 0x7f5968987467 in iconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/iconv_open.c:40
    #3 0x60200000004f  (<unknown module>)

Direct leak of 112 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f5968987914 in __GI___gconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/gconv_open.c:78
    #2 0x7f5968987467 in iconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/iconv_open.c:40
    #3 0x60300000183f  (<unknown module>)

Indirect leak of 32640 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f596898798f in __GI___gconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/gconv_open.c:128
    #2 0x7f5968987467 in iconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/iconv_open.c:40
    #3 0x60200000004f  (<unknown module>)

Indirect leak of 32640 byte(s) in 1 object(s) allocated from:
    #0 0x7f5969794808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f596898798f in __GI___gconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/gconv_open.c:128
    #2 0x7f5968987467 in iconv_open /build/glibc-BHL3KM/glibc-2.31/iconv/iconv_open.c:40
    #3 0x60300000183f  (<unknown module>)

Indirect leak of 416 byte(s) in 2 object(s) allocated from:
    #0 0x7f5969794808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
    #1 0x7f5968992a76 in __gconv_lookup_cache /build/glibc-BHL3KM/glibc-2.31/iconv/gconv_cache.c:366

SUMMARY: AddressSanitizer: 66688 byte(s) leaked in 9 allocation(s).
# 

My version: 3.0.5.33220.ds4-1build2
OS: ubuntu20.04 (docker)

Regards.

[AlexPeshkoff]

Sanitize leaks does not give you correct results with firebird. There are 2 reasons for it:

1. Own memory allocator, not using malloc (i.e. internal leaks will not be seen). valgrind works ok, but to use it one should build firebird sources with appropriate support.
2. Own schema of global var-s dtors execution - it's needed not to destroy an object which is in use by other objects and may be referenced in dtor of it. As a side effect memory, allocated by calls to 3-d party libraries (like iconv and icu), may appear as leak in sanitizer. Looks like it's invoked before we call object dtors. Must say I have no plans to change something related to dtors because of sanitizer.

[SakiTakamachi]

Thank you.

[dmitry-lipetsk]

I think this problem occurs because fbclient and server whole do not call u_cleanup.

[aafemt]

I wonder if u_cleanup() is safe to be called from DLLMain()...

[asfernandes]

I wonder if u_cleanup() is safe to be called from DLLMain()...

#7702 (comment)

[aafemt]

But IBM documentation doesn't mention anything that is prohibited in DLLMain() so perhaps u_cleanup() can be called from some global destructor. Minimally it can be called from fb_shutdown().

[dmitry-lipetsk]

I wonder if u_cleanup() is safe to be called from DLLMain()...

#7702 (comment)

I think, Firebird should work with ICU through "proxy" with counter of u_init/u_cleanup calls.

It allows to share ICU library with different modules.

The same counter must be in fbclient (+ fb_init function).

[asfernandes]

But IBM documentation doesn't mention anything that is prohibited in DLLMain() so perhaps u_cleanup() can be called from some global destructor. Minimally it can be called from fb_shutdown().

You didn't understood the problem.
ICU is shared library called by many applications.
Many loaded libraries may be using same ICU dlls.
You should not call it if you're not certainly you're the only ICU user, and we can't know that.

u_cleanup is also not thread-safe.

[asfernandes]

I wonder if u_cleanup() is safe to be called from DLLMain()...

#7702 (comment)

I think, Firebird should work with ICU through "proxy" with counter of u_init/u_cleanup calls.

It allows to share ICU library with different modules.

The same counter must be in fbclient (+ fb_init function).

Then ask and coordinate every user (including Java) to do the same.

Or better, ask ICU to make their functions better.