Geek Answers Handbook

C understanding valgrind, stack splitting error

I made a program that once throws a detected stack detection error. It works 99% of the time, but with certain files it throws an error. I used valgrind to try to 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 don't understand what the mistake is. I appreciate the help.

+4
source share
4 answers

you need to distinguish between stack errors and memory heaps.

Walgrind tells you that part of the memory has not been freed, and some may have been lost. but this may have nothing to do with your real problem: stack destruction.

stack means: local variables (often with character arrays), any other arrays that are not placed, etc.

heap: everything that was allocated using malloc, calloc, realloc, etc.

So if you break the stack, chances are good that you write somewhere on top of the end of the array. First check strcpy, memcpy, and array access (where you write to memory that was not allocated).

+6
source

With Valgrind 3.7.0 you can try the experimental tool exp-sgcheck which finds stacks and global overruns. As indicated, this is an experimental tool, so it may not be as high quality as memcheck and other non-experimental Valgrind tools. (for example, may give false positive and / or false negative values). exp-sgcheck, however, helped me one day to find a nasty array overflow error.

+2
source

With these messages, Valgrind tells you that the memory has been allocated (and shows you the stack trace of how the malloc call is called), but this memory has never been freed from these allocations.

More information can be found at http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks

0
source

valgrind does not detect array overruns , which could cause damage to your observed stack.

0
source

More articles:


All Articles