Find the answer to your Linux question:
Results 1 to 4 of 4
Hi, We have installed valgrind 3.3.1 on a Red Hat Enterprise Linux 5.1 operating system running on Vmware. We have developed an application which uses SQLite version 3.3.17. When we ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2008
    Posts
    4

    Wink RedHatLinux5.1,valgrind SQLite memory leak


    Hi, We have installed valgrind 3.3.1 on a Red Hat Enterprise Linux 5.1 operating system running on Vmware. We have developed an application which uses SQLite version 3.3.17.
    When we run valgrind 3.3.1 Memchecker on the application, we get an memory leak report:

    ==547== 144 bytes in 1 blocks are possibly lost in loss record 49 of 86
    ==547== at 0x400497E: calloc (vg_replace_malloc.c:397)
    ==547== by 0x618BD9: _dl_allocate_tls (in /lib/ld-2.5.so)
    ==547== by 0x79BB49: pthread_create@@GLIBC_2.1 (in /lib/libpthread-2.5.so)
    ==547== by 0x40CB7D4: testThreadLockingBehavior (os_unix.c:484)
    ==547== by 0x40CB99D: findLockInfo (os_unix.c:544)
    ==547== by 0x40CBDB8: sqlite3UnixOpenReadWrite (os_unix.c:72
    ==547== by 0x40CF273: sqlite3pager_open (pager.c:1632)
    ==547== by 0x40A98DE: sqlite3BtreeOpen (btree.c:1647)
    ==547== by 0x40CA7E8: sqlite3BtreeFactory (main.c:685)
    ==547== by 0x40CAE6E: openDatabase (main.c:885)
    ==547== by 0x40CAFA1: sqlite3_open (main.c:931)
    ==547== by 0x807F075: cSQLite::cSQLite(char*, bool) (cSQLite.cpp:27)

    The stack trace does not tell us where in the application the cSQLite class constructor is being called . However, we checked our application code and found that each cSQLite constructor call is matched by an explicit destructor call.

    We noticed that testThreadLockingBehavior() is a function that allows SQLite to test whether threads can override each other's locks. On Red Hat 9.0, we know that threads cannot override each other's locks.

    Does anyone know why we are getting this valgrind memory leak report on the latest release of Red Hat Enterprise Linux and how we can fix the memory leak? Thank you.

  2. #2
    Just Joined!
    Join Date
    Jul 2008
    Posts
    4

    Re: pthreads memory leak

    We ported our multithreaded C++ application to Sun Solaris 8 and used the dbx RunTimeChecker to test for memory leaks. We are still getting a memory leak related to pthreads . It appears the problem is not related to SQLite. Here is the dbx memory leak report we obtained:

    Memory Leak (mel):
    Found leaked block of size 8 bytes at address 0xe1d60
    At time of allocation, the call stack was:
    [1] calloc() at 0xf593615c
    [2] _ti_pthread_setspecific() at 0xf1d1427c
    [3] __Cimpl::ex_thread::get_thr_data() at 0xf8104830
    [4] __Cimpl::cplus_init() at 0xf8106220
    [5] _init() at 0xf599f9a8
    [6] call_init() at 0xff3bcadc
    [7] elf_bndr() at 0xff3c6dd4
    [8] elf_rtbndr() at 0xff3b2c04

    Memory Leak (mel):
    Found leaked block of size 4 bytes at address 0xe1d80
    At time of allocation, the call stack was:
    [1] realloc() at 0xfe92f700
    [2] _ti_pthread_setspecific() at 0xf1d142fc
    [3] __Cimpl::ex_thread::get_thr_data() at 0xf8104830
    [4] __Cimpl::cplus_init() at 0xf8106220
    [5] _init() at 0xf599f9a8
    [6] call_init() at 0xff3bcadc
    [7] elf_bndr() at 0xff3c6dd4
    [8] elf_rtbndr() at 0xff3b2c04


    Has anyone seen this memory leak before? Thank you.

  3. #3
    Just Joined!
    Join Date
    Jul 2008
    Posts
    4

    Re: pthreads memory leak

    We ported our multithreaded C++ application to Sun Solaris 8 and used the dbx RunTimeChecker to test for memory leaks. We are still getting a memory leak related to pthreads . It appears the problem is not related to SQLite. Here is the dbx memory leak report we obtained:

    Memory Leak (mel):
    Found leaked block of size 8 bytes at address 0xe1d60
    At time of allocation, the call stack was:
    [1] calloc() at 0xf593615c
    [2] _ti_pthread_setspecific() at 0xf1d1427c
    [3] __Cimpl::ex_thread::get_thr_data() at 0xf8104830
    [4] __Cimpl::cplus_init() at 0xf8106220
    [5] _init() at 0xf599f9a8
    [6] call_init() at 0xff3bcadc
    [7] elf_bndr() at 0xff3c6dd4
    [8] elf_rtbndr() at 0xff3b2c04

    Memory Leak (mel):
    Found leaked block of size 4 bytes at address 0xe1d80
    At time of allocation, the call stack was:
    [1] realloc() at 0xfe92f700
    [2] _ti_pthread_setspecific() at 0xf1d142fc
    [3] __Cimpl::ex_thread::get_thr_data() at 0xf8104830
    [4] __Cimpl::cplus_init() at 0xf8106220
    [5] _init() at 0xf599f9a8
    [6] call_init() at 0xff3bcadc
    [7] elf_bndr() at 0xff3c6dd4
    [8] elf_rtbndr() at 0xff3b2c04


    Has anyone seen this memory leak before? Thank you.

  4. #4
    Just Joined!
    Join Date
    Jul 2008
    Posts
    4

    [RESOLVED] RedHat Linux valgrind memory leak

    The problem is resolved. I wrote an email to Paul Pluzhnikov who you all know and he responded to my valgrind problem with the answer:

    "You can safely ignore (or suppress) this one."

    > Could you briefly explain to me why we can safely ignore this? Thank
    > you.

    The call is coming from glibc internals, which the user can't do
    anything about. It's also a one-time only allocation (happens first
    time pthread_create is called; only 1 block is allocated).

    For a more detailed answer, I'd have to fish out glibc-2.4 sources.

    Cheers,
    --
    Paul Pluzhnikov

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •