[SOLVED] still reachable: 28 bytes in 1 blocks- valgrind error

sjremya · 12-08-2010, 10:43 PM

I am using valgrind 3.6.0 for finding memory leak in my application.
this is one sample code i tested in Valgrind. This is similar to my actual 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 got the following output from valgrind.

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

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

neonsignal · 12-09-2010, 06:45 AM

The output of valgrind could be misleading in this case, because you are exiting the program immediately after cancelling the thread; you can easily end up reporting on the state of the heap before the thread has had a chance to exit. Try putting a small delay after the pthread_cancel, I think you will find that this will make the 'leak' vanish from your example code.

If your real code is using pthread_cancel to kill threads and you are having problems with losing RAM, it is possible that your threads are opening/allocating something that is not being cleaned up (for example, shared process resources such as handles).The pthread_cancel should be used with caution; it is often better if one can come up with a way of signalling a thread to terminate itself rather than to kill it, so that the exit is more structured. If you must use pthread_cancel, then pthread_cleanup_push is a way of supplying resource recovery code.

sjremya · 12-13-2010, 08:12 AM

@neonsignal : Thanks for ur suggestions

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