-
Notifications
You must be signed in to change notification settings - Fork 2
Useful commands & debugging
curl https://brew.42.fr/ | bash
rm -rf $HOME/.brew && git clone --depth=1 https://github.com/Homebrew/brew $HOME/.brew && echo 'export PATH=$HOME/.brew/bin:$PATH' >> $HOME/.zshrc && source $HOME/.zshrc && brew update
brew install readline
I recommend doing a leak check very often, basically every time you meddle with malloc and free. it is very important to keep track of the memory you're using and is a lot easier than to do it once after doing the whole project and then having to figure out wtf is going on. i know it can be annoying, but the good thing is, if you do it often, you'll get the hang of it and it will be easier to do in the future.
replace your readline("<prompt>") with ft_strdup("<command_you_want_to_test>")
this is helpful because readline has leaks and you only want to test for your OWN leaks. also remove add_history.
if you don't have the exit function yet, or you just want to use a single command, it is helpful to use break after one or multiple loops.
initialize docker with jeremie's guide, with one tiny addition:
- add this line to your dockerfile:
RUN apt-get install libreadline6 libreadline6-dev -y
with every new time you logged in and want to use it, you have to start docker with the init_docker.sh script from 42toolbox.
if you're on a new machine, also build the docker image with docker build -t memory-test ..
-
now, the command to actually use valgrind:
docker run -ti -v $(PWD):/test memory-test bash -c "cd /test/; make re && valgrind --leak-check=full --show-leak-kinds=all ./minishell"
it is a little different from the one by jeremie, it shows more leaks, but otherwise it's the same.
just as important as memory leaks are file descriptor leaks. don't forget about them, they are just as bad!
to check for open file descriptors, run lsof -c minishell in a different shell. it might be confusing at first, since there is a lot open, but usually, you only need to pay attention to 0u, 1u, 2u and whatever comes after. these three are the standard open file descriptors, and if 3, 4, 5 or other adjacent numbers are open, that is probably an fd leak if you are not using those in that moment. also pay attention to the type and name of file descriptors open. if your leaking fd's name starts with /dev/, you have probably duplicated one of the standard file descriptors. otherwise, it is pretty easy to see what exactly is open, in case of a pipe, it will be of type PIPE, in case of a file, you can check NAME for the name of the file.
- of course, there is also the classic way of debugging with
printf. with this, you can see when an error happens, to see which lines of code get executed, by seeing if your printf statement gets printed. you can also print out variables you're using, and see what their values are.
- IMPORTANT: add a
\nto your print statement, otherwise it might not get printed, even though the code goes in that direction. this is because of weird printf behavior.- here is the statement that i use:
printf("\e[43mhere?\e[0m\n");
- the vscode debugger is also really good! helps with keeping track of variables and their values, very useful. if you want to set it up, just hmu ^^
made by shaas