[SOLVED] still reachable: 28 bytes in 1 blocks

[sjremya]

Hi all

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


this is the application

#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.

==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

[Rubberman]

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.

[sjremya]

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

[Rubberman]

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.

[sjremya]

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