C understanding valgrind, stack smashing error

Question

I made a program that sometime it throws a stack smashing detected error. It works 99% of the time, but with certain files it throws the error. I used valgrind to try identify the error, but i am having trouble understanding the log file. So here it is:

==3797== Memcheck, a memory error detector
==3797== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3797== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==3797== Command: ./pargrep de nuevo.txt
==3797== Parent PID: 2367
==3797== 
==3797== 
==3797== HEAP SUMMARY:
==3797==     in use at exit: 33,339 bytes in 5 blocks
==3797==   total heap usage: 12 allocs, 7 frees, 35,025 bytes allocated
==3797== 
==3797== 4 bytes in 1 blocks are still reachable in loss record 1 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x8048FDB: maestro (padre.c:39)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 55 bytes in 1 blocks are still reachable in loss record 2 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40B878B: __libc_message (libc_fatal.c:138)
==3797==    by 0x413D09F: __fortify_fail (fortify_fail.c:32)
==3797==    by 0x413D049: __stack_chk_fail (stack_chk_fail.c:29)
==3797==    by 0x8049665: contar_palabra (funcion.c:51)
==3797==    by 0x80494C5: hilos_hijos (hilos.c:90)
==3797==    by 0x4041E98: start_thread (pthread_create.c:304)
==3797==    by 0x41279ED: clone (clone.S:130)
==3797== 
==3797== 136 bytes in 1 blocks are possibly lost in loss record 3 of 5
==3797==    at 0x4025315: calloc (vg_replace_malloc.c:467)
==3797==    by 0x4010CD7: allocate_dtv (dl-tls.c:300)
==3797==    by 0x401146B: _dl_allocate_tls (dl-tls.c:464)
==3797==    by 0x40425C6: pthread_create@@GLIBC_2.1 (allocatestack.c:570)
==3797==    by 0x80490E1: maestro (padre.c:84)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 352 bytes in 1 blocks are still reachable in loss record 4 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40B3537: __fopen_internal (iofopen.c:76)
==3797==    by 0x40B360B: fopen@@GLIBC_2.1 (iofopen.c:107)
==3797==    by 0x804907D: maestro (padre.c:66)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== 32,792 bytes in 1 blocks are still reachable in loss record 5 of 5
==3797==    at 0x4026864: malloc (vg_replace_malloc.c:236)
==3797==    by 0x40EBA18: __alloc_dir (opendir.c:186)
==3797==    by 0x40EBB49: opendir (opendir.c:141)
==3797==    by 0x8049013: maestro (padre.c:53)
==3797==    by 0x8048ABF: main (main.c:62)
==3797== 
==3797== LEAK SUMMARY:
==3797==    definitely lost: 0 bytes in 0 blocks
==3797==    indirectly lost: 0 bytes in 0 blocks
==3797==      possibly lost: 136 bytes in 1 blocks
==3797==    still reachable: 33,203 bytes in 4 blocks
==3797==         suppressed: 0 bytes in 0 blocks
==3797== 
==3797== For counts of detected and suppressed errors, rerun with: -v
==3797== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 8)

i really dont understand whats the error.I appreciate the help.

Answer 1

you need to differ between stack smashing and heap memory errors.

Valgrind is telling you that some memory has not been freed and some is possibly lost. but that might have nothing to do with your real problem: the stack smashing.

stack means: local variables (often char arrays), any other arrays which are not allocated etc.

heap: anything that has been alloced with malloc, calloc, realloc etc.

So if you get a stack smashing, chances are high, that you somewhere write over the end of an array. check strcpy, memcpy, and array access first (where you write to a memory which was not allocated).

Answer 2

With Valgrind 3.7.0, you might try the experimental tool exp-sgcheck which finds stack and global overruns. As indicated, this is an experimental tool, so might not be as high quality as memcheck and other non experimental Valgrind tools. (e.g. might give false positive and/or false negative). exp-sgcheck however helped me once to find a nasty array overrun bug.