Thank you for this helpful video! Is it correct that there is no library to apply assert like methods to detect leaks? Essentially there are only terminal based tools? The reason I ask is thinking about this in the context of a CI/CD automation, would someone need to setup the command line utility to run and check the code base or could it just be one of the series of tests?
I suspect folks could use leaks in a CI/CD system, and the terminal tools make that a bit easier. Something folks might do is actually use a technique known as interpositioning to overload calls to malloc, or in C++ overload the 'new' operator in a test build to also do logging. I'll have q video eventually on this 🙂
Thank you for the video! I'm having a hard time finding exactly where the leaks are in my code because there aren't any lines mentioned in the leak report, and in my class we just started using cmake files so I'm not sure how to run with debug symbols. Is there a way to use debug symbols with cmake, or another way to show the line numbers?
Generally speaking, both will gives you memory reports. Historically valgrind is seen as a more 'heavy weight' tool that provides more information versus leaks. Both are still actively developed as I understand though, so there may be other tradeoffs or tools incorporated in both frameworks to provide different bug profiles.
not to be pedantic, i want to share this for new programmers: you might not always want to/care enough to free. most unix cmd utilities don't free resources unless it is necessary logically, due to the assumption that the utility will run and exit really quickly. if you have a long running program, however, obviously you should free resources
Indeed, many applications only allocate (or just a specific 'bump allocator' that is never freed). :) As you say, knowing your problem, scope, and lifetime/maintenance of the program might make it unnecessary to free.
Idk why after export MallocStackLogging I have warning, for example: -> export MallocStackLogging=1 -> ls . ls(5316) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null) ls(5316) MallocStackLogging: stack logs being written to /tmp/stack-logs.5316.104788000.ls.1J0PCm.index ls(5316) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder ls(5316) MallocStackLogging: stack logs deleted from /tmp/stack-logs.5316.104788000.ls.1J0PCm.index
Thanks for this video, this is really helpful! I was wondering if you've encountered an issue that says a process isn't debuggable because "for security, cannot load non-system library"?
Hmm, maybe need to open the process once or run 'chmod u+x ./prog' before hand to give permissions? You can try running as 'sudo' if you are admin on the machine as well. Will have to look into this more.
@@MikeShah Thanks for the quick response! I tried using sudo and gave the executable file full permissions but was still getting the same results. The full message is the following: Can't examine target process's malloc zone asan_0x103979378, so memory analysis will be incomplete or incorrect. Reason: for security, cannot load non-system library (editing out file path)/libclang_rt.asan_osx_dynamic.dylib Process is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes. I've also sent a question to Apple's developer support, I'll let you know if they're able to sort it out!
@@MikeShah I think I figured it out! I'll post my findings here in case anyone else runs into the same issue. I had compiled my C executable with the address sanitizer, which is what prevented leaks from accessing the memory and why the error message mentioned the asan dylib. When I compile the C code without the address sanitizer enabled, the leaks output works like it does for you in the demonstration. Thanks again for your help!
@@MikeShah Sorry to resurrect this old thread! But I was using leaks on code that was experiencing a segmentation fault, and noticed something strange that the segmentation fault message wasn't displaying when leaks was enabled. Is this something you've ever run into, or do you know if there's a way to stop leaks from suppressing those kinds of messages? Thanks for your help!
Enabling the feature essentially logs additional information every time malloc is called (specifically the state of the call stack) developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html
HI Mike ! Thanks for your video. I tried to do the exact same thing as you mentioned in your video with a file. It works but i have a problem. there aren't any lines mentioned for the leaks so I can't check in my code where exactly i need to look at..
Hmm, I'm assuming you compiled with debug symbols as well? You also are unlikely to get line numbers from external libraries as well (as they were likely not compiled with debug)
@@MikeShah hi! I’m learning to program at the moment with the class CS50, I use their libraries. But I don’t use their VE, I use their library locally on my mac. To be able to compile my program that use their libraries, I created a makefile file that I put in the same folder as my C file in order to compile it. It enables me to compile my program by entering into the terminal make name_of_file The content of my makefile is: LDLIBS += -lcs50 CC := clang
@@MikeShah basically I get the exact same thing as you, but where the leak is mentionned, Everything is the same as you, start etc, but there is just not any line mentioned .. ahaha
@@marcello_s Ah yes, somewhere look to see if there is a '-g' that would indicate a 'debug build' The convention is to use something like: $(ARGS) as a variable and add in '-g'. You could otherwise try: make run ARGS="-g"
TOP! Im using macOS Monterey but the leaks tool show everything but not the source code with the leak. Do you have any tips (leaks Report Version: 3.0)?
Good question -- I would assume leaks hooks into various 'loadlibrary/dlload' functions to intercept calls to malloc on those libraries -- but I'm not sure. I'll have to cook something up to see if we can detect a leak
I have a util dynamic C library I made myself and I have a different source code repo that uses it. When I run in the repo that depends on the util dynamic library I get this leaks - -atExit -- ./$(EXECUTABLE_NAME) dyld[45586]: Library not loaded: libstandardloop-util.dylib It cannot locate my util dynamic lib. I have DYLD_LIBRARY_PATH set and DYLD_FALLBACK_LIBRARY_PATH set aswell. I have tried to set it before running the leaks command as well.
Running the excutable directly is totattly functional, but running the executable with leaks causes issues. I used man leaks but couldn't really see a flag to add to assist. Let me know if you find anything.
Are there any C++ IDEs free for students that have Leaks support? I've been having trouble finding any IDEs for later MacBook versions that support any sort of memory leak detection.
@@ahmetuzun2798 Try: #include int main(){ for(int i=0; i < 10; i++){ static int* o = NULL; o = malloc(300); } return 0; } I wonder if the memory in the heap is already being freed when exiting main. Perhaps leaks is a bit more conservative and only providing a report on memory it can prove that has been left out of scope. (Static variables themselves probably aren't 'freed' until the very end of a process, and in a sense, a static variable will always exist in the binary, so it will always hold onto at least 1 reference to the memory, thus why you'll only see 9 of the 10 leaks reported)
Thanks a lot! I'm combining your instructions with | grep "Call stack" to get rid off the rest of information. The only thing is that using 'C' I don't get the exact line, but... it's a great leap anyway!
@@MikeShah Thanks for your quick answer! The issue is I cannot use valgrind due to restrictions of installation (I'm in the 42 school of Barcelona). Also when my program is compiled with other auxiliar programs (used as sources of functions) I don't get the info about what program caused the leak. I'm exploring other options of the leaks command.
Does someone have a solution for this ??? export MallocStackLogging=1 env(93734) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null) env(93734) MallocStackLogging: stack logs being written to /tmp/stack-logs.93734.104660000.env.Fnog2c.index env(93734) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder bash(93734) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null) bash(93734) MallocStackLogging: stack logs being written to /tmp/stack-logs.93734.1006f8000.bash.gLUjp0.index bash(93734) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder bash(93734) MallocStackLogging: stack logs deleted from /tmp/stack-logs.93734.104660000.env.Fnog2c.index bash(93736) MallocStackLogging: stack logs deleted from /tmp/stack-logs.93734.1006f8000.bash.gLUjp0.index head(93737) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)
I've worked 3 hours to find an alternative to valgrind in mac and this video literally made my day thanks
Cheers, happy to hear that!
Thanks for this Video. Nice one. Since too many issues in installation of valgrind on MAC M1(ARM)
Cheers!
Actually helped me to find out places I forgot to free, tho I didn't manage to get the line numbers
Cheers!
Thank you for this helpful video! Is it correct that there is no library to apply assert like methods to detect leaks? Essentially there are only terminal based tools? The reason I ask is thinking about this in the context of a CI/CD automation, would someone need to setup the command line utility to run and check the code base or could it just be one of the series of tests?
I suspect folks could use leaks in a CI/CD system, and the terminal tools make that a bit easier. Something folks might do is actually use a technique known as interpositioning to overload calls to malloc, or in C++ overload the 'new' operator in a test build to also do logging. I'll have q video eventually on this 🙂
Thank you for the video! I'm having a hard time finding exactly where the leaks are in my code because there aren't any lines mentioned in the leak report, and in my class we just started using cmake files so I'm not sure how to run with debug symbols. Is there a way to use debug symbols with cmake, or another way to show the line numbers?
CMake should allow for debug builds which contain debugging symbols. Otherwise can add arguments with-g I believe in cmake to get debug
THANK YOU!! My class is supposed to use Valgrind but I can't get it to work on my Mac. Is there anything Valgrind does that this doesn't?
Generally speaking, both will gives you memory reports. Historically valgrind is seen as a more 'heavy weight' tool that provides more information versus leaks. Both are still actively developed as I understand though, so there may be other tradeoffs or tools incorporated in both frameworks to provide different bug profiles.
not to be pedantic, i want to share this for new programmers: you might not always want to/care enough to free.
most unix cmd utilities don't free resources unless it is necessary logically, due to the assumption that the utility will run and exit really quickly.
if you have a long running program, however, obviously you should free resources
Indeed, many applications only allocate (or just a specific 'bump allocator' that is never freed). :) As you say, knowing your problem, scope, and lifetime/maintenance of the program might make it unnecessary to free.
Idk why after export MallocStackLogging I have warning, for example:
-> export MallocStackLogging=1
-> ls .
ls(5316) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)
ls(5316) MallocStackLogging: stack logs being written to /tmp/stack-logs.5316.104788000.ls.1J0PCm.index
ls(5316) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder
ls(5316) MallocStackLogging: stack logs deleted from /tmp/stack-logs.5316.104788000.ls.1J0PCm.index
Me too ! I did not find a solution in the internet!
Does someone have a solution for this ??
Cool thank you for this video, It's been a while that I've been looking for an alternative to valgrind on mac
Cheers, you are most welcome!
Does it work for you? Because I have constant segfault trying to access to leaks -atExit-
If anyone needs this to turn off the MallocStackLogging in the terminal... set MallocStackLogging=0 doesn't turn it off.
"unset MallocStackLogging"
Perfect!
Thanks for this video, this is really helpful! I was wondering if you've encountered an issue that says a process isn't debuggable because "for security, cannot load non-system library"?
Hmm, maybe need to open the process once or run 'chmod u+x ./prog' before hand to give permissions? You can try running as 'sudo' if you are admin on the machine as well. Will have to look into this more.
@@MikeShah Thanks for the quick response! I tried using sudo and gave the executable file full permissions but was still getting the same results. The full message is the following:
Can't examine target process's malloc zone asan_0x103979378, so memory analysis will be incomplete or incorrect.
Reason: for security, cannot load non-system library (editing out file path)/libclang_rt.asan_osx_dynamic.dylib
Process is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
I've also sent a question to Apple's developer support, I'll let you know if they're able to sort it out!
@@MikeShah I think I figured it out! I'll post my findings here in case anyone else runs into the same issue. I had compiled my C executable with the address sanitizer, which is what prevented leaks from accessing the memory and why the error message mentioned the asan dylib. When I compile the C code without the address sanitizer enabled, the leaks output works like it does for you in the demonstration. Thanks again for your help!
@@TheBloodlessOne awesome, nice fix!
@@MikeShah Sorry to resurrect this old thread! But I was using leaks on code that was experiencing a segmentation fault, and noticed something strange that the segmentation fault message wasn't displaying when leaks was enabled. Is this something you've ever run into, or do you know if there's a way to stop leaks from suppressing those kinds of messages? Thanks for your help!
Very clear explaination!
Cheers!
Very helpful, thanks! can you explain more about "export MallocStackLogging=1 "?
Enabling the feature essentially logs additional information every time malloc is called (specifically the state of the call stack) developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html
how do you turn off the stack logging afterwards?
Try: export MallocStackLogging=0 or 'unset MallocStackLogging'
HI Mike ! Thanks for your video. I tried to do the exact same thing as you mentioned in your video with a file. It works but i have a problem. there aren't any lines mentioned for the leaks so I can't check in my code where exactly i need to look at..
Hmm, I'm assuming you compiled with debug symbols as well? You also are unlikely to get line numbers from external libraries as well (as they were likely not compiled with debug)
@@MikeShah hi! I’m learning to program at the moment with the class CS50, I use their libraries. But I don’t use their VE, I use their library locally on my mac. To be able to compile my program that use their libraries, I created a makefile file that I put in the same folder as my C file in order to compile it. It enables me to compile my program by entering into the terminal
make name_of_file
The content of my makefile is:
LDLIBS += -lcs50
CC := clang
@@MikeShah basically I get the exact same thing as you, but where the leak is mentionned,
Everything is the same as you, start etc, but there is just not any line mentioned .. ahaha
@@marcello_s Ah yes, somewhere look to see if there is a '-g' that would indicate a 'debug build'
The convention is to use something like: $(ARGS) as a variable and add in '-g'.
You could otherwise try: make run ARGS="-g"
@@MikeShah i don’t think I get it. I’m sorry I’m new to programming. I really don’t know what I should do right now to fix this :/
TOP! Im using macOS Monterey but the leaks tool show everything but not the source code with the leak. Do you have any tips (leaks Report Version: 3.0)?
I'm assuming you've compiled with debug symbols?
How to handle if my excutable uses a dynamic library?
Good question -- I would assume leaks hooks into various 'loadlibrary/dlload' functions to intercept calls to malloc on those libraries -- but I'm not sure. I'll have to cook something up to see if we can detect a leak
I have a util dynamic C library I made myself and I have a different source code repo that uses it.
When I run in the repo that depends on the util dynamic library I get this
leaks - -atExit -- ./$(EXECUTABLE_NAME)
dyld[45586]: Library not loaded: libstandardloop-util.dylib
It cannot locate my util dynamic lib. I have DYLD_LIBRARY_PATH set and DYLD_FALLBACK_LIBRARY_PATH set aswell. I have tried to set it before running the leaks command as well.
Running the excutable directly is totattly functional, but running the executable with leaks causes issues. I used man leaks but couldn't really see a flag to add to assist.
Let me know if you find anything.
Thanks! absolute saver
Cheers!
thank you for making this video! it was very helpful ^^
You are most welcome!
Are there any C++ IDEs free for students that have Leaks support? I've been having trouble finding any IDEs for later MacBook versions that support any sort of memory leak detection.
I haven't used xcode in some time, but I believe that has a memory analyzer (maybe using leaks) integrated
Is there a way to locate invalid reads too? (e.g. Reading freed memory).
How to installe it ? Homebrew does not have a « leaks » package
Check /usr/bin to see if it i on your mac already (might be installed alongside xcode). Otherwise you can try 'brew install leaks'
Amazing, thank you!
Cheers!
when I alloc in static variable in c without free the leaks tool don't show me the leak ....
Interesting, so if you have: static int* p = NULL; Then do something like p = malloc(sizeof(int)*10) leaks does not catch the memory leak?
@@MikeShah yep
static int *o = NULL;
o = malloc(300);
0 leaks for 0 total leaked bytes
@@ahmetuzun2798 Try:
#include
int main(){
for(int i=0; i < 10; i++){
static int* o = NULL;
o = malloc(300);
}
return 0;
}
I wonder if the memory in the heap is already being freed when exiting main. Perhaps leaks is a bit more conservative and only providing a report on memory it can prove that has been left out of scope. (Static variables themselves probably aren't 'freed' until the very end of a process, and in a sense, a static variable will always exist in the binary, so it will always hold onto at least 1 reference to the memory, thus why you'll only see 9 of the 10 leaks reported)
@@MikeShah okkkkk thxxx
very helpful 👏
Awesome!
very helpful! thank you!
Cheers!
Thanks a lot! I'm combining your instructions with | grep "Call stack" to get rid off the rest of information. The only thing is that using 'C' I don't get the exact line, but... it's a great leap anyway!
Cheers, glad to hear it! Hmm, maybe using -g3 will provide more debug information to valgrind?
@@MikeShah Thanks for your quick answer! The issue is I cannot use valgrind due to restrictions of installation (I'm in the 42 school of Barcelona). Also when my program is compiled with other auxiliar programs (used as sources of functions) I don't get the info about what program caused the leak. I'm exploring other options of the leaks command.
@@XavierCatalaBaltaAh, got it!
Nice video!
Thank you!
Thanks
Cheers!
👍👍👍👍👍👍👍👍👍👍👍👍
Cheers!
Does someone have a solution for this ???
export MallocStackLogging=1
env(93734) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)
env(93734) MallocStackLogging: stack logs being written to /tmp/stack-logs.93734.104660000.env.Fnog2c.index
env(93734) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder
bash(93734) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)
bash(93734) MallocStackLogging: stack logs being written to /tmp/stack-logs.93734.1006f8000.bash.gLUjp0.index
bash(93734) MallocStackLogging: recording malloc and VM allocation stacks to disk using standard recorder
bash(93734) MallocStackLogging: stack logs deleted from /tmp/stack-logs.93734.104660000.env.Fnog2c.index
bash(93736) MallocStackLogging: stack logs deleted from /tmp/stack-logs.93734.1006f8000.bash.gLUjp0.index
head(93737) MallocStackLogging: could not tag MSL-related memory as no_footprint, so those pages will be included in process footprint - (null)