[c++] Tool per errori con la memoria

[Sabonis]

Mi sapete consigliare qualche buon tool per scoprire errori di memoria come memory leak, buffer overflow etc?
Valgrind è molto buono ma non trova errori di questo tipo:

int static[5];

int main(void)
{
int stack[5];

static[5] = 0;
stack [5] = 0;

return 0;
}

Esiste qualche tool che possa trovare errori di questo genere?

[VICIUS]

Non vedo errori nel codice tranne l'uso di una parola chiave come nome di variabile ma per questo basta un qualsiasi compilatore.

[marko.fatto]

Originariamente inviato da VICIUS

Non vedo errori nel codice tranne l'uso di una parola chiave come nome di variabile ma per questo basta un qualsiasi compilatore.

forse che il quinto elemento è in posizione 4 mentre quello a cui cerca di accedere sarebbe il sesto elemento?

[Unrue]

Originariamente inviato da Sabonis

Mi sapete consigliare qualche buon tool per scoprire errori di memoria come memory leak, buffer overflow etc?
Valgrind è molto buono ma non trova errori di questo tipo:

int static[5];

int main(void)
{
int stack[5];

static[5] = 0;
stack [5] = 0;

return 0;
}

Esiste qualche tool che possa trovare errori di questo genere?

Si, esiste. E' una particolare versione di gcc, chiamato bounds-checking. E' una patch da applicare. Funziona molto bene, rileva sforamenti sia nello stack che nell'heap.

Dopo che hai scaricato la patch:
http://sourceforge.net/project/showf...group_id=88372

Compila con -fbounds-checking. L'unica cosa è che non so se funziona anche con C++. ma tanto il codice che hai scritto è C

[VICIUS]

Originariamente inviato da marko.fatto

forse che il quinto elemento è in posizione 4 mentre quello a cui cerca di accedere sarebbe il sesto elemento?

Cavolo hai ragione. Sono troppo abituato a ruby/c#

[71104]

Originariamente inviato da VICIUS

Cavolo hai ragione. Sono troppo abituato a ruby/c#

non mi risulta che in C# gli indici degli array partano da 1

[Sabonis]

Originariamente inviato da Unrue

Si, esiste. E' una particolare versione di gcc, chiamato bounds-checking. E' una patch da applicare. Funziona molto bene, rileva sforamenti sia nello stack che nell'heap.

Dopo che hai scaricato la patch:
http://sourceforge.net/project/showf...group_id=88372

Compila con -fbounds-checking. L'unica cosa è che non so se funziona anche con C++. ma tanto il codice che hai scritto è C

Mi servirebbe un tool per il c++!

[Unrue]

Originariamente inviato da Sabonis

Mi servirebbe un tool per il c++!

Mi pare che si possa applicare anche a g++. Prova

E comunque, se programmi in C++, la cosa migliore è usare i vector, che con il metodo at() controllano gli indici nativamente.

[DanieleC88]

Originariamente inviato da VICIUS

Non vedo errori nel codice tranne l'uso di una parola chiave come nome di variabile ma per questo basta un qualsiasi compilatore.

Questa è l'età...

Quel codice, se fosse un film, si chiamerebbe...

Il Quinto Elemento!

ok, scappo da solo...

[71104]

Originariamente inviato da Unrue

E comunque, se programmi in C++, la cosa migliore è usare i vector, che con il metodo at() controllano gli indici nativamente.

mah, non credo che valga la pena di usare i vector per un problema del genere; i vantaggi di vector sono altri, ma se si tratta di usare un array di dimensioni note e fisse usare vector non è certo meglio che usare qualche sistema per il controllo degli errori di memoria.

[71104]

Originariamente inviato da DanieleC88

Questa è l'età...

Quel codice, se fosse un film, si chiamerebbe...

Il Quinto Elemento!

ok, scappo da solo...

asdasdasdasdasdasdasdasdasd

[Unrue]

Originariamente inviato da 71104

mah, non credo che valga la pena di usare i vector per un problema del genere; i vantaggi di vector sono altri, ma se si tratta di usare un array di dimensioni note e fisse usare vector non è certo meglio che usare qualche sistema per il controllo degli errori di memoria.

In C++ non credo esista altro per controllare gli indici. Quindi mi pare l'unica soluzione praticabile.

Neanche Valgrind prende quegli errori purtroppo. E poi non è detto che lui debba lavorare solo con array a dimensioni fisse

Un'alternativa più spinta è compilare ll codice da controllare con il gcc patchato con bounds checking e tutto il resto passarlo al compilatore c++. Però non l'ho mai fatto e sinceramente non so neanche se sia fattibile.

[71104]

Originariamente inviato da Unrue

In C++ non credo esista altro per controllare gli indici. Quindi mi pare l'unica soluzione praticabile.

si può anche scrivere un piccolo template ad hoc, che risulterebbe meglio di vector perché quest'ultima ha un problema: il bound checking lo fa sempre, ma nella build di release è inutile. tra l'altro ribadisco che secondo me è inutile scomodare vector se le dimensioni dell'array sono fisse.

questo è un template che ho scritto or ora e che potrebbe rimpiazzare gli array normali:

template<typename _Type, int _Size>
class CheckedArray
{
private:
	_Type Data[_Size];

public:
	inline _Type &operator [] (unsigned int Index)
	{
		assert(Index < _Size);
		return Data[_Size];
	}

};

non ci vuole niente a scriverlo e risolve il problema meglio di vector.

[Unrue]

Originariamente inviato da 71104

si può anche scrivere un piccolo template ad hoc, che risulterebbe meglio di vector perché quest'ultima ha un problema: il bound checking lo fa sempre, ma nella build di release è inutile.

Non è vero. Il bound checking il vector lo fa solo se accedi con questa sintassi all'elemento i:

vettore.at(i);

Dunque con il metodo at(). Se ci accedi direttamente:

vettore(i);

Non fa alcun controllo. Dunque in fase di debug usi at(). In release, togli il metodo e ci accedi direttamente.

Originariamente inviato da 71104

questo è un template che ho scritto or ora e che potrebbe rimpiazzare gli array normali:

template<typename _Type, int _Size>
class CheckedArray
{
private:
	_Type Data[_Size];

public:
	inline _Type &operator [] (unsigned int Index)
	{
		assert(Index < _Size);
		return Data[_Size];
	}

};

non ci vuole niente a scriverlo e risolve il problema meglio di vector.

Beh, a mano puoi fare tutto. Lui chiedeva se c'era un tool che già lo fa. Dunque, a parte il gcc patchato (che non sono sicuro che vada con C++) ed i vector, non c'è nulla

[71104]

Originariamente inviato da Unrue

Non è vero. Il bound checking il vector lo fa solo se accedi con questa sintassi all'elemento i:

vettore.at(i);

Dunque con il metodo at(). Se ci accedi direttamente:

vettore(i);

Non fa alcun controllo. Dunque in fase di debug usi at(). In release, togli il metodo e ci accedi direttamente.

su che hai capito benissimo: a parte che l'operatore per l'accesso diretto sono le parentesi quadre, non le tonde, ma a parte quello il metodo at il bound checking lo fa sempre, sia in modalità di debug che di release; e riempire il codice di #ifdef _DEBUG ad ogni singolo accesso al vettore mi sembra eccessivo, così i tempi di scrittura si quintuplicano

Beh, a mano puoi fare tutto.

no, a mano non puoi fare tutto: se una cosa non è ragionevole farla non la fai. ma se ti preme il bound checking questa soluzione mi sembra ragionevolissima per quanto poco tempo e quante poche modifiche al codice esistente richiede.

[Unrue]

Originariamente inviato da 71104

su che hai capito benissimo: a parte che l'operatore per l'accesso diretto sono le parentesi quadre, non le tonde,

Ah beh, errore colossale.. Non c'è bisogno di rispondere con ironia a fronte di sviste..

Originariamente inviato da 71104

ma a parte quello il metodo at il bound checking lo fa sempre, sia in modalità di debug che di release; e riempire il codice di #ifdef _DEBUG ad ogni singolo accesso al vettore mi sembra eccessivo, così i tempi di scrittura si quintuplicano

Non mi hai capito: io ho detto che il bound checking il vector lo fa con il metodo at, se ci accedi direttamente no. MI pareva di aver scritto chiaro..

Nessun ifdef nel codice. In debug usi il metodo at, in release lo togli. Quante milioni di volte lo userai mai nel codice..

[71104]

Originariamente inviato da Unrue

Ah beh, errore colossale.. Non c'è bisogno di rispondere con ironia a fronte di sviste..

anima candida, quella la chiami ironia?

ecco, questa è ironia

Nessun ifdef nel codice. In debug usi il metodo at, in release lo togli.

appunto... l'ifdef serve a vedere se sei in debug o in release:

#ifdef _DEBUG
... vettore.at(i) ...
#else
... vettore[i] ...
#endif

Quante milioni di volte lo userai mai nel codice..

e che ne sai, può essere un programma che fa un uso intensivo degli array, tantopiù se gli preme il bound checking.

[sottovento]

Originariamente inviato da Sabonis

Mi sapete consigliare qualche buon tool per scoprire errori di memoria come memory leak, buffer overflow etc?
Valgrind è molto buono ma non trova errori di questo tipo:

int static[5];

int main(void)
{
int stack[5];

static[5] = 0;
stack [5] = 0;

return 0;
}

Esiste qualche tool che possa trovare errori di questo genere?

La piattaforma e' Windows? In tal caso, hai a disposizione diverse tecniche per riuscire a trovare errori di questo tipo, specialmente se usi Visual...

[Sabonis]

Originariamente inviato da sottovento

La piattaforma e' Windows? In tal caso, hai a disposizione diverse tecniche per riuscire a trovare errori di questo tipo, specialmente se usi Visual...

Si va bene sia per windows che per linux che per mac

[marco.r]

Originariamente inviato da 71104

si può anche scrivere un piccolo template ad hoc, che risulterebbe meglio di vector perché quest'ultima ha un problema: il bound checking lo fa sempre, ma nella build di release è inutile.

Eventuali bug spariscono automaticamente ?