Need more information about Aborted (core dumped)

Question

This bellow code will generate Aborted (core dumped) at last line.

code:

  #include <stdio.h>
  #include <malloc.h>

  int main()
  {
    char *ptr;
    ptr=malloc(sizeof(char)*10);
    free(ptr);
    free(ptr);     // core dumped
  }

output is:

*** glibc detected *** ./a.out: double free or corruption (fasttop): 0x091f7008 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7665ee2]
./a.out[0x804846d]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb76094d3]
./a.out[0x8048371]
======= Memory map: ========
08048000-08049000 r-xp 00000000 fc:00 4070236    /home/gangadhar/a.out
08049000-0804a000 r--p 00000000 fc:00 4070236    /home/gangadhar/a.out
0804a000-0804b000 rw-p 00001000 fc:00 4070236    /home/gangadhar/a.out
091f7000-09218000 rw-p 00000000 00:00 0          [heap]
b75ba000-b75d6000 r-xp 00000000 fc:00 22938319   /lib/i386-linux-gnu/libgcc_s.so.1
b75d6000-b75d7000 r--p 0001b000 fc:00 22938319   /lib/i386-linux-gnu/libgcc_s.so.1
b75d7000-b75d8000 rw-p 0001c000 fc:00 22938319   /lib/i386-linux-gnu/libgcc_s.so.1
b75ef000-b75f0000 rw-p 00000000 00:00 0 
b75f0000-b7794000 r-xp 00000000 fc:00 22937623   /lib/i386-linux-gnu/libc-2.15.so
b7794000-b7795000 ---p 001a4000 fc:00 22937623   /lib/i386-linux-gnu/libc-2.15.so
b7795000-b7797000 r--p 001a4000 fc:00 22937623   /lib/i386-linux-gnu/libc-2.15.so
b7797000-b7798000 rw-p 001a6000 fc:00 22937623   /lib/i386-linux-gnu/libc-2.15.so
b7798000-b779b000 rw-p 00000000 00:00 0 
b77b1000-b77b4000 rw-p 00000000 00:00 0 
b77b4000-b77b5000 r-xp 00000000 00:00 0          [vdso]
b77b5000-b77d5000 r-xp 00000000 fc:00 22937715   /lib/i386-linux-gnu/ld-2.15.so
b77d5000-b77d6000 r--p 0001f000 fc:00 22937715   /lib/i386-linux-gnu/ld-2.15.so
b77d6000-b77d7000 rw-p 00020000 fc:00 22937715   /lib/i386-linux-gnu/ld-2.15.so
bf7e0000-bf801000 rw-p 00000000 00:00 0          [stack]
Aborted (core dumped)

Here I'm interested to know in which cases these core dumped will occur?

Can we find out at which line this is occurred without using debugger?

what information it is showing(about shared libraries)?

Adriell

If you compile with debugging symbols (-ggdb for GCC) you can see the lines on which errors happen. Strictly speaking these core dumps will occur whenever the compiler/running platform feels like since freeing a pointer that has already been freed is undefined behaviour. – Encomiast

why it is showing shared libraries and their permissions? – Adriell

Because free resides in libc (with which your program is automatically linked), and that's where the dumping of core happens. In more complicated bugs this information is useful for tracking where exactly the problem occurs since a program may crash on one line in one source file but the actual bug may be in a linked library. – Encomiast

Answer 1

Core dump file generally gets created when a program terminates abnormally. Calling free() twice on a pointer causes segmentation fault. That's why you are getting coredumped. You can find some information here about calling free on same pointer twice.

Massproduce

calling free more than 1 time will lead core dumped. I agree. Is there any other case same problem will come? – Adriell

@Adriell when you try to modify a read-only block of memory – Rrhagia

Answer 2

Since it has been many years since you asked the question, I am just adding this answer in case any other user finds this helpful.

As @Chinna stated in his answer, core dump files are created when a program crashes or terminates abnormally in Linux (also called crash dumps in Windows), and it contains the program state at the time of crash, i.e memory, register values, call stack etc. Unhandled exceptions, illegal memory access, and overflowing the program stack are some common cases that lead to a segmentation fault or an aborted message and create a core dump file.

Usually, you require a debugger to get the call traceback and check where the crash occured. But if you do not want to or cannot use a debugger, a good logging system embedded in your program can help you pinpoint the location of the crash by going through the logs later.

Metchnikoff