ValGrind : It's leaking :)

Those of you who haven't heard about ValGrind : It is Gates of Death or gates of Valhalla in Norse Mythology.

I just love mythology.  I am not sure, how true it is , but for the time humans were born it existed.
It is our fear , our love , our redemption.

Its changes as humans changes, it is ever evolving.

But this post is not about Gates of Valhalla. ( Does Max max : Fury Road) rings a bell

This post is about second ValGrind : Which is debugging tool suite, It has one tool called MEMCHECK, which helps in checking if your C or C++ program is leaking memory.

Now in the older post, we have seen how to debug crash and know why your program crashed. But seriously, we will not always wait for our program to crash. So we use Memcheck to see if our program gotta piss or not.


1) If you want to use something, you need to have it.  So install it first on your linux machine. Pretty easy. Simply run

> sudo apt-get install valgrind. 

2) I will take the example, where my .C file is  crash.c and my program is crash. To run on this you have to give below command.

> valgrind --tool=memcheck --leak-check=full ./crash

Now what happens is that the output of this command will come on your terminal and which is not easy to read.

So better put that into some file  say "val.txt".

> valgrind --tool=memcheeck --leak-check=full -log-file="val.txt" ./crash


now for my below code, the valgrind output was

Crash.c file 

#include<stdio.h>
#include<stdlib.h>

void voldemort(int *);

int main()
{
   int *hp;
   hp=(int *)malloc(sizeof(int)*1);
   voldemort(hp);
  // free(hp);
}

void voldemort(int *hp)
{
  int *temp;
  temp = hp;
  *temp=2; 
  hp=NULL;
  *hp=10;

}


Valgrind output

==8949== Memcheck, a memory error detector
==8949== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8949== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==8949== Command: ./crash
==8949== Parent PID: 5602
==8949== 
==8949== Invalid write of size 4
==8949==    at 0x8048463: voldemort (crash.c:20)
==8949==    by 0x8048441: main (crash.c:10)
==8949==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8949== 
==8949== 

==8949== Process terminating with default action of signal 11 (SIGSEGV): dumping core

So if you see , it is telling that at line 20 , there is invalid write. which if we see in crash.c file is correct, and we can modify our program to handle it.


So thats it ...

PLUG the LEAK

Core Dump : part 2

In last post, we saw about GDB, and BT . In this post we will work 1-2 more functions

So let see for below code. 

#include<stdio.h>
#include<stdlib.h>

void voldemort(int *);

int main()
{
   int *hp;
   hp=(int *)malloc(sizeof(int)*1);
   free(hp);
   voldemort(hp);
}

void voldemort(int *hp)
{
  free(hp);
}

On running I got below error

*** Error in `./crash': double free or corruption (fasttop): 0x0a04b008 ***
Aborted (core dumped)

This is my gdb - bt message

#0  0xb76df424 in __kernel_vsyscall ()
#1  0xb7548827 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb754bc53 in __GI_abort () at abort.c:89
#3  0xb7583993 in __libc_message (do_abort=do_abort@entry=1,
    fmt=fmt@entry=0xb7680a5c "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#4  0xb758de7a in malloc_printerr (action=<optimized out>,
    str=0xb7680c20 "double free or corruption (fasttop)", ptr=0xa04b008)
    at malloc.c:4996
#5  0xb758eaed in _int_free (av=0xb76c5420 <main_arena>,
    p=<optimized out>, have_lock=0) at malloc.c:3840
#6  0x08048491 in voldemort ()
#7  0x0804847e in main ()

As we can see at step 4, double corruption has taken place. 

And in step 5 , we have called  system function and Step 4 is Voldemort . 

So we got function in which error has occurred.

One more example:

#include<stdio.h>

#include<stdlib.h>

void voldemort(int *);

int main()

{

   int *hp;

   hp=(int *)malloc(sizeof(int)*1);

   voldemort(hp);

  // free(hp);

}

void voldemort(int *hp)

{

  int *temp;

  temp = hp;

  *temp=2; 

  hp=NULL;

  *hp=10; 

 

}

On running this I got 
 Segmentation fault (core dumped)

gdb-bt  output is 

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x08048463 in voldemort ()
(gdb) bt
#0  0x08048463 in voldemort ()
#1  0x08048442 in main ()

So as you can see with different type of signal , information can change a bit.

now we know Voldemort is bad guy and causing crash. So we need to check voldemort in detail.

Now if you have noted , then we can see that in front of every fucntion there is one number. To go inside a function we need that number with frame cmd. Example to go inside voldemort, we have to on gdb type below 

(gdb) frame 0                              // this will select this function, then we can use further gdb cmds                                                          list,   info locals

but when I typed, I ran into an error 'SYMBOL table info not available'. This is because at the time of building I have not enabled debugger option.

So I need to use that , like below .   crash.c  is my .c file name, crash will be name of my executable.

> gcc -g -o crash crash.c

Now when I run ./crash , in crashed as expected.  now after running gdb on it .

It automatically gave me line number where crash is happening. AWESOME

#0  0x08048463 in voldemort (hp=0x0) at crash.c:20
#1  0x08048442 in main () at crash.c:10

But to continue our tute, lets select this function

(gdb) frame 0
(gdb) list                    // list the function code
(gdb) info locals          // gives details about local variables.

For my function, below is details


(gdb) frame 0
#0  0x08048463 in voldemort (hp=0x0) at crash.c:20
20  *hp=10;
(gdb) list
15 {
16  int *temp;
17  temp = hp;
18  *temp=2;
19  hp=NULL;
20  *hp=10;
21
22
23 }
(gdb) info locals
temp = 0xa04b008
(gdb)

Now , we have seen that how can be debug crash dump using gdb.  

To quit gdb, simply paste q

But still lot needs to be debugged, like  what are memory address and what are values stored in them.

useful when crash is not happening, but answer is not as expected. 

that we will see in further tutes.

Core Dump : part 1

Well ...if u spend significant time on learning one language and slowly slowly or quickly depending on how much you are interested in that language ..you will try to see its different facets of that language.

So since I mostly work on C, I use to see lot of segmentation fault happening when writing program related to pointers or stackoverflow.  In all these cases COREDUMPS are generated, which tells memory wise what went wrong.

Now , mostly I don't use to see this, but go back to program and try to figure out what went wrong.

This works if your program is 1-2 files only and simple. Else its very hard to know why crash happened.

So i started to read about how to check core-dump in gcc.

Below is what i learned.

1) Is core dump getting generated ? 

Even though your gcc will say core dump is generated, but you will see it is not present. It happens because your SHELL doesn't have permission to generated coredump by default.

hence you have to run below command.

> ulimit -c unlimited.

NOTE : ulimit is shell property, so when you start running your program you have to run above cmd first. So any program then run on that will generate core dump.

2) Checking Core Dump#

1) Run below cmd :  
> gdb <executable> <core-file> or gdb <executable> -c <core-file>

Example I have c file name crash.c and core dump generated name is core, so i will run

> gdb ./crash core

This will give some information on my screen.

My .c program was

#include<stdio.h> #include<stdlib.h> int main() { int p[0]; int b=10; p[0];//=(int*) malloc(sizeof(int)*1); printf("b %d\n",b); printf("%p %p %p",&b,&p[0],&p[1]); p[1]=20; printf("b %d\n",b); free(p); // This is point where crash should occur //p=&b; }


Output of running cmd which mentioned below is

Core was generated by `./crash'. Program terminated with signal SIGABRT, Aborted. #0 0xb76df424 in __kernel_vsyscall ()







So as you can see with above message, you cannot do any shit with your program. Hence you have to use gdb next command -- bt . It stands for backtrace and prints the stack of program.




when i run bt below thing I got




(gdb) bt

#0  0xb76df424 in __kernel_vsyscall ()

#1  0xb7548827 in __GI_raise (sig=sig@entry=6)

    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56

#2  0xb754bc53 in __GI_abort () at abort.c:89

#3  0xb7583993 in __libc_message (do_abort=do_abort@entry=1, 

    fmt=fmt@entry=0xb7680a5c "*** Error in `%s': %s: 0x%s ***\n")

    at ../sysdeps/posix/libc_fatal.c:175

#4  0xb758de7a in malloc_printerr (action=<optimized out>, 

    str=0xb767c56d "free(): invalid pointer", ptr=0xbf7fc108)

    at malloc.c:4996

#5  0xb758eaed in _int_free (av=0xb76c5420 <main_arena>, 

    p=<optimized out>, have_lock=0) at malloc.c:3840

#6  0x080484c1 in main ()

As you can see, something makes a bit sense now.

Since stack is LIFO, the first line ( from last) tells as what was function entered in which we had crash, it was MAIN().

now, when we called free, it defination would hav been in malloc.c , since it is pointed next.

Line 4 is telling as 'free() : invalid pointer' so we can see our pointer there and can see that it is not correct.

Voila our program is debugged. In next tute , we will see more better code.