Find the answer to your Linux question:
Results 1 to 5 of 5
Hi all I am using valgrind 3.6.0 for finding memory leak in my application. this is the application Code: #include <unistd.h> #include <pthread.h> void *start_routine(void *arg) { sleep(60); return 0; ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined! sjremya's Avatar
    Join Date
    May 2010
    Location
    India
    Posts
    39

    [SOLVED] still reachable: 28 bytes in 1 blocks


    Hi all

    I am using valgrind 3.6.0 for finding memory leak in my application.


    this is the application
    Code:
    #include <unistd.h>
    #include <pthread.h>
    
    void *start_routine(void *arg)
    {
    sleep(60);
    return 0;
    
    }
    
    int main()
    {
    pthread_attr_t attr;
    pthread_t th;
    
    pthread_attr_init(&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    
    pthread_create(&th, &attr, start_routine, NULL);
    
    pthread_attr_destroy(&attr);
    
    sleep(1);
    
    pthread_cancel(th);
    
    return 0;
    }
    I am getting the following error.

    Code:
    ==22589== HEAP SUMMARY:
    ==22589==     in use at exit: 28 bytes in 1 blocks
    ==22589==   total heap usage: 3 allocs, 2 frees, 524 bytes allocated
    ==22589==
    ==22589== 28 bytes in 1 blocks are still reachable in loss record 1 of 1
    ==22589==    at 0x4023CBE: malloc (vg_replace_malloc.c:236)
    ==22589==    by 0x400CE43: _dl_map_object_deps (in /lib/ld-2.5.so)
    ==22589==    by 0x4011E34: dl_open_worker (in /lib/ld-2.5.so)
    ==22589==    by 0x400E025: _dl_catch_error (in /lib/ld-2.5.so)
    ==22589==    by 0x4011928: _dl_open (in /lib/ld-2.5.so)
    ==22589==    by 0x4449F01: do_dlopen (in /lib/libc-2.5.so)
    ==22589==    by 0x400E025: _dl_catch_error (in /lib/ld-2.5.so)
    ==22589==    by 0x444A000: dlerror_run (in /lib/libc-2.5.so)
    ==22589==    by 0x444A12A: __libc_dlopen_mode (in /lib/libc-2.5.so)
    ==22589==    by 0x405AE66: pthread_cancel_init (in /lib/libpthread-2.5.so)
    ==22589==    by 0x405AF90: _Unwind_ForcedUnwind (in /lib/libpthread-2.5.so)
    ==22589==    by 0x4058950: __pthread_unwind (in /lib/libpthread-2.5.so)
    ==22589==
    ==22589== LEAK SUMMARY:
    ==22589==    definitely lost: 0 bytes in 0 blocks
    ==22589==    indirectly lost: 0 bytes in 0 blocks
    ==22589==      possibly lost: 0 bytes in 0 blocks
    ==22589==    still reachable: 28 bytes in 1 blocks
    ==22589==         suppressed: 0 bytes in 0 blocks
    ==22589==
    ==22589== For counts of detected and suppressed errors, rerun with: -v
    ==22589== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 3)
    emmys0126:/opt/mdas # valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./mdas-pc
    ==24173== Memcheck, a memory error detector
    ==24173== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
    ==24173== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
    ==24173== Command: ./mdas-pc
    Please help me to find out where the 28 bytes leaks ?

    Regards
    SJR

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Sometimes system functions create static data structures for bookkeeping purposes and there is nothing you can do about it. They show up on leak detection tools such as valgrind or Purify. Once you know what they are, you can usually configure the tool to ignore them. In any case, there is nothing in the simple code you posted that would qualify as a "memory leak". So, don't sweat it!

    FWIW, I have been doing large-scale system development for many, many years - systems that have to run 24x365 where memory leaks are not viable. I do use these tools extensively to determine if any code is showing leaks, so I have some (20+ years) experience with it.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined! sjremya's Avatar
    Join Date
    May 2010
    Location
    India
    Posts
    39
    Quote Originally Posted by Rubberman View Post
    Sometimes system functions create static data structures for bookkeeping purposes and there is nothing you can do about it. They show up on leak detection tools such as valgrind or Purify. Once you know what they are, you can usually configure the tool to ignore them. In any case, there is nothing in the simple code you posted that would qualify as a "memory leak". So, don't sweat it!

    FWIW, I have been doing large-scale system development for many, many years - systems that have to run 24x365 where memory leaks are not viable. I do use these tools extensively to determine if any code is showing leaks, so I have some (20+ years) experience with it.
    Thanks for the response

    This is only a sample code which resembles our actual application.

    In our application also we are getting the same message in Valgrind. And when we run the application 24x7 , there is a reduction in RAM size (In our embedded board, total available RAM is 64 MB) . And after few hours, it is reducing to 1.3MB and board communication fails.

    Is this problem has any relation with the Valgrind error "still reachable: 28 bytes in 1 blocks" ? Usually what will be the cause of RAM reduction?

    Regards
    SJR

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,755
    Well, a report from your actual software after it has run awhile would be useful. This report simply says that _dl_map_object_deps has malloc'd 28 bytes when it opened a shared library. They are reachable, but not lost (leaked) as per the report. So, this doesn't tell you enough about what's going on.

    One thing that can cause seeming leaks (but not real ones) in running systems is memory fragmentation. That's why in embedded systems you want to pre-allocate all the memory your software will need as a local buffer, and then have your own allocator that provides parts of it to the application when it needs memory. Basically, you are rolling your own malloc/free. Usually, you need to do a detailed code analysis to determine where you are allocating/freeing memory. If your code is C++, the classes that are the most problematic can have class new/delete operators that do this. An example would be Rogue-Wave's string class in their Tools.h++ class library. Any string smaller than some specified size comes out of a chunk of memory controlled by the class instead from the OS.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Just Joined! sjremya's Avatar
    Join Date
    May 2010
    Location
    India
    Posts
    39

    Solved

    Hi this memory leak issue is solved..


    bugs

    1. In file handling. We were not closing a file properly.
    2. Memory was not freed after an alloc sys call


    Regards

    SJR

Posting Permissions

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