summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorFreeArtMan <dos21h@gmail.com>2022-08-18 10:34:32 +0100
committerFreeArtMan <dos21h@gmail.com>2022-08-18 10:34:32 +0100
commit0c14cd279ad4e1ec3588e1360a510f3bdf7925f5 (patch)
tree6263532fd46593a18c486d2e65c142d2f521d946
parent6f77120968b59f1fe4d69abc3ab79e6abb9053fc (diff)
downloadmd-content-0c14cd279ad4e1ec3588e1360a510f3bdf7925f5.tar.gz
md-content-0c14cd279ad4e1ec3588e1360a510f3bdf7925f5.zip
valgrind
-rw-r--r--md/notes/undefined_c/titles.md140
1 files changed, 140 insertions, 0 deletions
diff --git a/md/notes/undefined_c/titles.md b/md/notes/undefined_c/titles.md
index 6053291..ec8f0b5 100644
--- a/md/notes/undefined_c/titles.md
+++ b/md/notes/undefined_c/titles.md
@@ -1069,6 +1069,146 @@ void _start() {
http://main.lv/writeup/making_c_executables_smaller.md
### Memory leaks
+
+Memory leaks is cruitial part of C language. Default case when they are detected are
+when allocated memory wasn free'd after use. If amount of this type of memory increasing then
+its can eventually fill whole memory and system will be unresponsive. Here is simple example
+how memory leak created and how to detect it.
+
+```c
+#include <stdlib.h>
+
+int main() {
+
+ char *ptr = malloc(12);
+
+ return 0;
+}
+```
+
+The best way to detect it to use valgrind.
+
+```
+$ valgrind ./malloc
+
+==778== HEAP SUMMARY:
+==778== in use at exit: 12 bytes in 1 blocks
+==778== total heap usage: 2 allocs, 1 frees, 1,036 bytes allocated
+```
+
+There is seen 2 allocs and 1 free. But we see that 12bytes after exit. So our created leak is detected.
+More complex example. So now we created leaking function and we called it 5 times. But in larger code
+base it would be nice to see location of leaks.
+
+```c
+#include <stdlib.h>
+
+int* mem_alloc(int sz) {
+ int *ret=NULL;
+
+ if (sz < 0) {
+ return NULL;
+ }
+
+ ret = malloc(sz*sizeof(int));
+
+ if (sz>10) {
+ return NULL;
+ }
+
+ return ret;
+
+}
+
+int main() {
+
+ mem_alloc(0);
+
+ free(mem_alloc(1));
+
+ mem_alloc(100);
+
+ free(mem_alloc(2));
+
+ mem_alloc(10);
+
+ return 0;
+}
+```
+
+There is 3 blocks that leaks, and we see where its comming from there is possible to guess but it would better
+to have position of where leak located.
+
+```
+valgrind --leak-check=full --track-origins=yes --log-file=log.txt ./memleak2
+
+==4974== HEAP SUMMARY:
+==4974== in use at exit: 440 bytes in 3 blocks
+==4974== total heap usage: 5 allocs, 2 frees, 452 bytes allocated
+==4974==
+==4974== 0 bytes in 1 blocks are definitely lost in loss record 1 of 3
+==4974== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==4974== by 0x109179: mem_alloc (in /home/fam/prog/c/undefined_c/memleak2)
+==4974== by 0x10919E: main (in /home/fam/prog/c/undefined_c/memleak2)
+==4974==
+==4974== 40 bytes in 1 blocks are definitely lost in loss record 2 of 3
+==4974== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==4974== by 0x109179: mem_alloc (in /home/fam/prog/c/undefined_c/memleak2)
+==4974== by 0x1091D6: main (in /home/fam/prog/c/undefined_c/memleak2)
+==4974==
+==4974== 400 bytes in 1 blocks are definitely lost in loss record 3 of 3
+==4974== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==4974== by 0x109179: mem_alloc (in /home/fam/prog/c/undefined_c/memleak2)
+==4974== by 0x1091BA: main (in /home/fam/prog/c/undefined_c/memleak2)
+==4974==
+==4974== LEAK SUMMARY:
+==4974== definitely lost: 440 bytes in 3 blocks
+==4974== indirectly lost: 0 bytes in 0 blocks
+==4974== possibly lost: 0 bytes in 0 blocks
+==4974== still reachable: 0 bytes in 0 blocks
+==4974== suppressed: 0 bytes in 0 blocks
+```
+
+Add compilation option __g3__
+
+```
+gcc -g3 memleak2.c -o memleak2
+```
+
+Now it shows source lines and trace from where the leaking code where called. Thats looks better now.
+
+```
+valgrind --leak-check=full --track-origins=yes --log-file=log.txt ./memleak2
+
+==5073== HEAP SUMMARY:
+==5073== in use at exit: 440 bytes in 3 blocks
+==5073== total heap usage: 5 allocs, 2 frees, 452 bytes allocated
+==5073==
+==5073== 0 bytes in 1 blocks are definitely lost in loss record 1 of 3
+==5073== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==5073== by 0x109179: mem_alloc (memleak2.c:10)
+==5073== by 0x10919E: main (memleak2.c:22)
+==5073==
+==5073== 40 bytes in 1 blocks are definitely lost in loss record 2 of 3
+==5073== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==5073== by 0x109179: mem_alloc (memleak2.c:10)
+==5073== by 0x1091D6: main (memleak2.c:30)
+==5073==
+==5073== 400 bytes in 1 blocks are definitely lost in loss record 3 of 3
+==5073== at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
+==5073== by 0x109179: mem_alloc (memleak2.c:10)
+==5073== by 0x1091BA: main (memleak2.c:26)
+==5073==
+==5073== LEAK SUMMARY:
+==5073== definitely lost: 440 bytes in 3 blocks
+==5073== indirectly lost: 0 bytes in 0 blocks
+==5073== possibly lost: 0 bytes in 0 blocks
+==5073== still reachable: 0 bytes in 0 blocks
+==5073== suppressed: 0 bytes in 0 blocks
+==5073==
+```
+
+
### Code coverage
### Profiling
### Canary