Why my program automatically frees things? - c

I'm trying to do a program for a university task and I'm receiving this message from Valgrind:
==4244== HEAP SUMMARY:
==4244== in use at exit: 300 bytes in 2 blocks
==4244== total heap usage: 5 allocs, 3 frees, 2,428 bytes allocate
I don't know where this 3 frees comes from because when I erased all of my free functions these 3 stayed there. I thought that when a function returns without freeing things, that'd be a case of memory leak.
My question is: why it isn't? Does a function frees everything declared in it when it returns? If so, how do I know that a function is successfully freeing the stuff declared in there?

Stuff gets malloc()ed and free()ed in code outside of your source, such as library functions. Valgrind sees all of that.

Related

Does sem_close deallocates memory created with sem_open?

For a project written in C, I am creating a number of semaphore with sem_open, some are binary other are counting, I don't think it matters. The semaphores are stored in a static structure (singleton) then I fork the process multiple time, and afterwards exit all my forks. The main process returns however only after I used sem_close() followed by sem_unlink() on all my semaphores.
void init_semaphore(void)
{
ru->stop = sem_open("/stop", O_CREAT, 0644, 1);
...
}
void sem_close_all(void)
{
sem_close(ru->stop);
...
sem_unlink("/stop");
}
When I run valgrind I get the following errors:
==744644== 39 bytes in 1 blocks are still reachable in loss record 10 of 13
==744644== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==744644== by 0x49107A8: __sem_check_add_mapping (sem_routines.c:104)
==744644== by 0x49104BB: sem_open##GLIBC_2.34 (sem_open.c:192)
==744644== by 0x10A34F: init_semaphore
==744644== by 0x10A0A9: init_all
==744644== by 0x10A05E: main
So I don't understand how to avoid those leaks that (I think) happens in my children ?... Note: I can't use sem_destroy because of project restriction.
Am I doing something wrong ? I tried to use free() on sem_t *stop, but it didn't get rid of the leaks. Is there a solution I could use to fix this, is it a valgrind false positive ?... I tried to use my sem_close_all() function at the end of all my process, but this does not fix the valgrind leak report.
I would not worry too much about it. Valgrind suppresses many other known memory leaks.
The error-checking tools detect numerous problems in the system
libraries, such as the C library, which come preinstalled with your
OS. You can't easily fix these, but you don't want to see these errors
(and yes, there are many!) So Valgrind reads a list of errors to
suppress at startup. A default suppression file is created by the
./configure script when the system is built.
You can manually add it permanently yourself
tried to use free() on sem_t *stop
Do not do this.

Incorrect Time-Stamps In Valgrind Memory Leak Report

I am running Valgrind over a large code-base, with "--time-stamp=yes"
I need to find out the ACTUAL (Relative) TIMESTAMPS at which each Memory was Allocated
Problem: Valgrind Report contains the Time-Stamps at which Leak Summary is generated
Steps:
- Run the codebase for 24 Hours with valgrind [ options
"--tool=memcheck --leak-check=full --time-stamp=yes"]
- Terminate the process with "kill -15" after 24 hours, Leak Summary is
generated.
- Time-Stamps In Valgrind Report= Time of Leak Report Generation [Not
the Actual Time at which Memory was Allocated]
Is there any option thorough which I can get the ACTUAL TIMESTAMPS -- at which Leaked Memory was Allocated ?
Thanks
No, there isn't, because leaks are not detected in real time - there isn't really any way to do that. Instead they are detected by scanning memory when the program finishes, to see what blocks are still reachable - anything which has been allocated but is not reachable is a leak.

HEap memory for running process [duplicate]

This question already has answers here:
How to check heap size for a process on Linux
(5 answers)
Closed 9 years ago.
Actually my code has malloc. I'm using ubuntu OS and I want to know how much heap memory is used?
Is there any command by which I can find how much heap a running process has used in ubuntu OS?
Say now the malloc is in infinite loop and it is running in one terminal and using another terminal I would like to know how much Heap memory is occupied by that running process
you can use /proc file system
/proc/pid/shmam
It will tell you exactly how much memory it is using at that time.
for detailed inputs refer
https://serverfault.com/questions/48582/how-is-memory-usage-reported-in-linux
How to measure actual memory usage of an application or process?
If you really want to know what amount of memory your application actually uses, you need to run it within a profiler. For example, valgrind can give you insights about the amount of memory used, and, more importantly, about possible memory leaks in your program.
look into,
http://valgrind.org/docs/manual/mc-manual.html
Valgrind is basically an x86 emulator that checks all reads and writes of memory, intercepts all calls to allocate and deallocate memory. The memcheck tool of valgrind can detect the following:
1) Use of uninitialised memory,
2) Reading/writing memory after it has been free'd
3) Reading/writing off the end of malloc'd blocks
4) Reading/writing inappropriate areas below the stack.
5) Memory leaks
6) Mismatched use of malloc/new/new[] vs free/delete/delete[]
7) Overlapping src and dst pointers in memcpy() and related functions
8) Doubly freed memory
9) Passing unaddressable bytes to a system call

Valgrind error: invalid write of size 4 (but says error is in free() )

First, here is the message valgrind gives me (this is just one error, I get the same message several times)
==25248== Invalid write of size 4
==25248== at 0x4024B3A: free (vg_replace_malloc.c:366)
==25248== by 0x8048F5E: sthread_free_ctx (sthread_ctx.c:86)
==25248== by 0x80489C1: sthread_user_exit (sthread_user.c:105)
==25248== by 0x804883C: dispatcher (sthread_user.c:40)
==25248== Address 0x41a6148 is 65,376 bytes inside a block of size 65,536 free'd
==25248== at 0x4024B3A: free (vg_replace_malloc.c:366)
==25248== by 0x8048F5E: sthread_free_ctx (sthread_ctx.c:86)
==25248== by 0x80489C1: sthread_user_exit (sthread_user.c:105)
==25248== by 0x804883C: dispatcher (sthread_user.c:40)
I dont understand it, because I am used to getting this error when I dont malloc enough space, so why am I getting the error when I am trying to free something?? what is being written?
thanks
It is difficult to tell with so little information (particularly: no code), but it looks to me like you may be attempting to call free on a pointer which refers to an offset into a memory region which has already been freed by an earlier call to free. free needs to manipulate the heap data structures, so it is not surprising that it is attempting to write to the memory region.

Valgrind complains while working with threads

I have created 20 threads to read/write a shared file.I have synchronized threads.
Now My program works fine but when I run it with valgrind it gives me Errors like this:
LEAK SUMMARY:
**definitely lost: 0 bytes in 0 blocks.
\
**possibly lost: 624 bytes in 5 blocks.**
**still reachable: 1,424 bytes in 5 blocks.****
suppressed: 0 bytes in 0 blocks.
Reachable blocks (those to which a pointer was found) are not shown.
Also When I press Ctrl + c , it gives the same errors.
I have not even malloced anything but still valgrind complains.
Any suggestion would be appreciated .
You can run valgrind --leak-check=full ./prog_name to make sure these reachable blocks are not something you can destroy in your program. Many times initializing a library such as libcurl without closing or destroying it will cause leaks. If it's not something you have control over, you can write a suppression file. http://valgrind.org/docs/manual/mc-manual.html section 4.4 has some info and a link to some examples
Sill reachable blocks are probably caused by your standard library not freeing memory used in pools for standard containers (see this faq): which would be a performance optimisation for program exit, since the memory is immediately going to be returned to the operating system anyway.
"Possibly lost" blocks are probably caused by the same thing.
The Valgrind Manual page for memcheck has a good explanation about the different sorts of leaks detected.

Resources