Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Memory leak of isc_attach_database #7849

Closed
SakiTakamachi opened this issue Nov 17, 2023 · 9 comments
Closed

Memory leak of isc_attach_database #7849

SakiTakamachi opened this issue Nov 17, 2023 · 9 comments

Comments

@SakiTakamachi
Copy link

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.
@SakiTakamachi SakiTakamachi mentioned this issue Nov 17, 2023
Merged
@KentarouTakeda KentarouTakeda mentioned this issue Nov 17, 2023
Merged
@AlexPeshkoff
Copy link
Member

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.

@AlexPeshkoff AlexPeshkoff closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2023
@SakiTakamachi
Copy link
Author

Thank you.

@dmitry-lipetsk
Copy link
Contributor

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

@aafemt
Copy link
Contributor

aafemt commented Dec 4, 2023

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

@asfernandes
Copy link
Member

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

#7702 (comment)

@aafemt
Copy link
Contributor

aafemt commented Dec 4, 2023

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
Copy link
Contributor

dmitry-lipetsk commented Dec 4, 2023 •
edited
Loading

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
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@asfernandes @AlexPeshkoff @dmitry-lipetsk @aafemt @SakiTakamachi