I want to test the mcheck functionality on my PC first to detect the malloc consolidate error. This way, i will be sure that this will help to figure out a similar crash on embedded-linux box. Unfortunately, the crash takes atleast 3-4 days. Thus, I am looking for a sample program that will generate the similar kind of crash as shown below.
Program terminated with signal 6, Aborted.
#0 0x2c73ebb8 in __syscall_kill (pid=900, sig=6) at kill.c:15
15 static inline _syscall2(int, __syscall_kill, __kernel_pid_t, pid,
int, sig);
Current language: auto; currently c
#0 0x2c73ebb8 in __syscall_kill (pid=900, sig=6) at kill.c:15
__res = 716485696
__err = 16
#1 0x2c73eb5c in kill (pid=900, sig=6) at kill.c:19
No locals.
#2 0x2aafb2e0 in pthread_kill (thread=900, signo=6) at signals.c:73
handle = (pthread_handle) 0x2ab3f2e0
pid = 900
#3 0x2aafbbb8 in raise (sig=6) at signals.c:241
retcode = 6
#4 0x2c730a5c in abort () at abort.c:94
sigset = {__val = {32, 0 <repeats 31 times>}}
#5 0x2c738054 in __malloc_consolidate (av=0x2c798860) at free.c:227
fb = (mfastbinptr *) 0x2c798864
maxfb = (mfastbinptr *) 0x2c798880
p = (mchunkptr) 0x2c798894
nextp = (mchunkptr) 0x4a2b2948
unsorted_bin = (mchunkptr) 0x2c798894
first_unsorted = (mchunkptr) 0x4a22f7e0
nextchunk = (mchunkptr) 0x2c798894
size = 0
nextsize = 0
prevsize = 0
nextinuse = 1
bck = (mchunkptr) 0x4a2b2948
fwd = (mchunkptr) 0x4a2b2948
#6 0x2c735ff0 in __malloc_inner (bytes=300) at malloc.c:912
av = (mstate) 0x2c798860
nb = 304
idx = 32
bin = (mbinptr) 0x2ac0dab4
fb = (mfastbinptr *) 0x2ae11e50
victim = (mchunkptr) 0x2ac0d9a4
size = 719396432
victim_index = 718311332
remainder = (mchunkptr) 0x49759b58
remainder_size = 40000
block = 719396432
bit = 718500504
map = 719396432
fwd = (mchunkptr) 0x1
bck = (mchunkptr) 0x4a2164ac
sysmem = (void *) 0x4975c9ac
#7 0x2c736c18 in malloc (bytes=300) at malloc.c:1172
That's because your program destroyed the data structure of memory management used by libc malloc/free. malloc/free has its own data residents in user program space to keep track on the list of allocated/freed space in different chunk size. Somehow, maybe your program has buffer overrun or unsafe random access that modified the data or pointer of memory management. And at the time point of your program calling malloc/free, it uses wrong address and cause the segfault or abort.
Running valgrind is extremely slow. Maybe you can try setenv MALLOC_CHECK_ to 1 and run your program to see any diagnosis message first.
Is this what you are asking for?
Example if you create a heap named *txt with size 100 char.
Then by mistake reasign smaller variable to that pointer:
Then trying to assign a normal text into the faulty heap;
Could be that you need to trace the variable (pointer) and check every reassignment.