### Description
I have compiled Kamailio with `MEMPKG=sys` param and Google Sanitizers. Then started/stopped Kamailio with default config. After Kamailio stopped the produced report below.
``` ==8042==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 15872 byte(s) in 124 object(s) allocated from: #0 0x7f01775ed36f in __interceptor_malloc (/lib64/libasan.so.6+0xab36f) #1 0x1296835 in addstr core/cfg.lex:1605 #2 0x129660e in addchar core/cfg.lex:1589 #3 0x1287356 in yylex core/cfg.lex:1266 #4 0x12be8c2 in yyparse core/cfg.tab.c:5508 #5 0x466c2d in main /tmp/kamailio/src/main.c:2487 #6 0x7f01768a91e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
Direct leak of 6784 byte(s) in 53 object(s) allocated from: #0 0x7f01775ed36f in __interceptor_malloc (/lib64/libasan.so.6+0xab36f) #1 0x1296835 in addstr core/cfg.lex:1605 #2 0x12894c7 in yylex core/cfg.lex:1395 #3 0x12be8c2 in yyparse core/cfg.tab.c:5508 #4 0x466c2d in main /tmp/kamailio/src/main.c:2487 #5 0x7f01768a91e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
Direct leak of 6104 byte(s) in 9 object(s) allocated from: #0 0x7f01775ed36f in __interceptor_malloc (/lib64/libasan.so.6+0xab36f) #1 0xbf1e09 in register_module core/sr_module.c:257 #2 0xc0c31c in load_module core/sr_module.c:641 #3 0x12d3b70 in yyparse core/cfg.y:1861 #4 0x466c2d in main /tmp/kamailio/src/main.c:2487 #5 0x7f01768a91e1 in __libc_start_main (/lib64/libc.so.6+0x281e1) ``` Full report [kamailio-sanitizer.log](https://github.com/kamailio/kamailio/files/7387628/kamailio-sanitizer.log)
### Additional Information Compiled 1483ddb735c3fa3ea77b6e2d54ec67584e56e15b
Thanks for the report. I think that the memory is not (completely) freed during the shutdown. But this is not a memory leak as the memory will be released after the application was stopped. I have change the description accordingly.
I looked at the entire log and all reports are related to config parsing and module fixups, which are done only once when kamailio is started. Like Henning said, all these memory fragments are needed during runtime and cleaned up automatically by OS when the application is stopped.
Closing it.
Closed #2892.
My opinion. Will be useful to clean this also. Reason - on real config with the real call we observe high shared memory usage by TLS module. Cleanup of this waring will prevent parse this it again and again.
These are pkg (private) memory fragments, not shared memory. It is not easy to clean them up in all forked processes (as they are cloned upon `fork()`). If you want, you can make pull requests cleaning them as much as you can.
Daniel @miconda Could you confirm the correct approach in memory cleanup?
You would need to free in both the parent and the child....
[link](https://www.linuxquestions.org/questions/programming-9/malloc-in-parent-free...)
One more [link](https://www.reddit.com/r/cprogramming/comments/57pg5s/dynamically_allocated_...)
When you fork a process, all of the malloc-heap structures will become COW by virtue of living within privately mapped page contents, which means that you can malloc, then fork, and then safely/correctly free the same pointer in the parent and child process. (Note also that the same rules apply to function returns—a single function call pre-fork can result in two valid returns post-fork with no problems, because the stack and stack management structures will be COWed.) “Required” doesn’t really enter into it TBH; if you no longer need something and it’s allocated usually, free it once you’re in the new process.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
sergey-safarov