Cześć, użyłem tego programu do przetestowania bardzo prostego kodu ze wskaźnikami. I o ile nie zostały wykryte wycieki pamięci, o tyle w logach dostałem informacje o błędach. Co one oznaczają? Kompilacje i test wykonałem następującymi komendami:
gcc -o0 -g main.c && valgrind --leak-check=full -v ./0
Screenshot z błędami:
Powiem Ci, że ja tutaj nie mam żadnych błędów z valgrinda:
C #include <stdio.h>
#include <stdlib.h>
int main(void)
{
int **ptr = malloc(sizeof(int) * 5);
int i = 0;
for(; i < 5; ++i) ptr[i] = malloc(sizeof(int) * 10);
for(i = 0; i < 5; ++i) free(ptr[i]);
free(ptr);
return 0;
}
Log:
==3653== Memcheck, a memory error detector
==3653== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3653== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3653== Command: ./c_programming
==3653==
==3653==
==3653== HEAP SUMMARY:
==3653== in use at exit: 0 bytes in 0 blocks
==3653== total heap usage: 6 allocs, 6 frees, 220 bytes allocated
==3653==
==3653== All heap blocks were freed -- no leaks are possible
==3653==
==3653== For counts of detected and suppressed errors, rerun with: -v
==3653== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Takie rzeczy jak Tobie się wyświetlają to pojawiają się nawet przy zwykłym wywołaniu, bez -v czy --leak-check=full. Naturalnie sprawdziłem też z tymi opcjami i null.
Nie mam ich nawet z flagami gcc, które zastosowałeś.
Aha, a komunikaty masz chociażby tutaj: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.errormsgs
@grzesiek51114 Masz starszą wersję tego programu.
Nie zmienia to faktu, że kod jest prawidłowy i nawet po przepisaniu na C99 wycieków tutaj nie ma i nie powinno być nic zgłaszane przez valgrinda. Wersja valgrinda też nie powinna mieć tutaj nic do rzeczy, bo to jest bardzo prosty kod.
To ja już sam nie wiem. Jak chcesz, to mogę nawet wysłać film, gdzie robię to wszystko. Sprawdzałem wszystko czy na pewno kompiluję prawidłowy plik, itp. a mam ciągle takie błędy.
Robię nawet z palucha: gcc -o0 -g -std=c99 main.c i log czyściutki.
@grzesiek51114:
To powiem Ci, że ja też nic tutaj nie widzę. No chyba, że jest już późna pora i jutro razem cudownie zobaczymy błąd :)
A weź wpisz w pierwszym mallocu sizeof (int*). Tutaj jest pewnie problem. Alokujesz wskaźniki na podtablice, a nie gotowe inty.
Innego pomysłu nie mam. Nie wiem... rozmiary są nie takie i marzesz to nie swojej pamięci. Sprawdź z ciekawości, bo kompa już wyłączyłem i pisze z tel.
@grzesiek51114 trafił w sedno. Ci którzy budują do architektury 32 bitowej błędu nie zauważają. Ty budujesz do architektury 64 bitowej (co widać przez ułamek sekundy na filmiku amd64).
Czyli rozmiar adresów ma 64 bity, ale int nadal ma 32 bity, więc koniec końców pierwsza alokacja jest za mała i wykraczasz poza zakres tablicy.
Zamiast posługiwać się typem w sizeof lepiej używać zmiennej:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int **ptr = (int **)malloc(sizeof(*ptr) * 5);
int i = 0;
for(; i < 5; ++i) ptr[i] = (int *)malloc(sizeof(**ptr) * 10);
for(i = 0; i < 5; ++i) free(ptr[i]);
free(ptr);
return 0;
}
Polecam używać Address Sanitizer zamiast valgrinda.
Jest skuteczniejszy, szybszy i daje jaśniejsze raport o błedach.
Przykładowo clang na Mac:
=================================================================
==72999==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000fce0 at pc 0x000104765e56 bp 0x7fff5b49ab40 sp 0x7fff5b49ab38
WRITE of size 8 at 0x60300000fce0 thread T0
#0 0x104765e55 in main test.c:8
#1 0x7fffd04b6234 in start (libdyld.dylib:x86_64+0x5234)
0x60300000fce4 is located 0 bytes to the right of 20-byte region [0x60300000fcd0,0x60300000fce4)
allocated by thread T0 here:
#0 0x1047c118c in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5618c)
#1 0x104765dfa in main test.c:6
#2 0x7fffd04b6234 in start (libdyld.dylib:x86_64+0x5234)
SUMMARY: AddressSanitizer: heap-buffer-overflow test.c:8 in main
Shadow bytes around the buggy address:
0x1c0600001f40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0600001f50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0600001f60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0600001f70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0600001f80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c0600001f90: fa fa fa fa fa fa fa fa fa fa 00 00[04]fa fa fa
0x1c0600001fa0: 00 00 00 00 fa fa 00 00 01 fa fa fa 00 00 00 fa
0x1c0600001fb0: fa fa fd fd fd fd fa fa fd fd fd fa fa fa 00 00
0x1c0600001fc0: 00 00 fa fa 00 00 00 fa fa fa 00 00 00 fa fa fa
0x1c0600001fd0: 00 00 00 00 fa fa fd fd fd fd fa fa fd fd fd fa
0x1c0600001fe0: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==72999==ABORTING
Abort trap: 6
Rozmiar inta niekoniecznie ma coś wspólnego z architekturą, z różnych względów... Zawsze trzeba odpowiednio używać sizeof, nigdy nie należy liczyć na wartości domyślne, bo nie zawsze są takie, jak się spodziewamy. Rozmiary typów mogą być różne w C++:
http://en.cppreference.com/w/cpp/language/types
Chyba, że to typy ściśle określone co do rozmiaru jak np. int64_t.
grzesiek51114