Newsgroup: it.comp.lang.c
Titolo: suggerimento per trovare un baco

ho sviluppato un programma sotto linux e funziona. se lo controllo con
valgrind sembra funzionare bene, non si lamenta nč di memoria persa nč
di scritture nei posti sbagliati.
Oggi ho provato a dargli in pasto dati molto piů grossi e il programma
crasha su routine su cui non crasha mai e che sono corrette.
Siccome non so dove sbattere la testa, vi chiedo se secondo voi ha senso
che possa essere lo stack troppo grande che va a quel paese. Come posso
capirlo? (e eventualmente risolverlo?) conoscete opzioni del gcc che
permettano di capire se č questo il problema?

 crasha su routine su cui non crasha mai e che sono corrette.
forse sul gruppo di sviluppo su linux sapranno aiutarti di piu',
ma intanto hai provato a compilarlo per il debugging con
gcc -O0 -g etc.etc.
e poi a farlo eseguire dal debugger visuale ddd, in modo
da evidenziare esattamente dove si pianta  e perche' ?
A quel punto poi puoi vedere lo stato delle variabili,
capire quale e' fuori scala e procedendo a ritroso
(facendo altri run in cui metti dei watch sulle variabili
incriminate) capire dove e' l'origine del problema.
Scusa se il suggerimento e' troppo puerile e l'avevi gia'
considerato.
ciao,
g.

 gcc -O0 -g etc.etc.
compilo sempre cosě.... :-(

 compilo sempre così.... :-(
si, ma hai provato a lanciarlo da ddd ?
g.

 si, ma hai provato a lanciarlo da ddd ?
col gdb. non credo che cambi molto. Crasha per motivi ignoti, mi dą
segfault scorrendo delle matrici usando indici corretti. Quindi temo che
si sputtani qualcos'altro...

 si sputtani qualcos'altro...
anche perchéla cosa tragicomica è che le stesse funzioni, eseguite
sigonalrmente sul dataset funzionano. messe assieme crashano.
Il mio terrore è che siccme ho degli array di 704*576 int16_t nelle
funzioni questi mi mandino lo stack in vacca quando iniziano ad essere
tanti...

 tanti...
scusa, ma se hai questi dubbi perche' non usi
l'allocazione dinamica ?
(ddd ha il vantaggio di essere visuale e penso sia piu'
intuitivo da usare di gdb se uno (come me) non e' un esperto
di debugging)
ciao,
g.

 g.
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 tutto puo' rimanere abbastanza trasparente (ovviamente ci sono alcune 
...intendevo dire: ...trasparente e semplice da modificare (il codice)


 l'allocazione dinamica ?
lo sto facendo...è che è un bel po' di codice......

 ...intendevo dire: ...trasparente e semplice da modificare (il codice)
ma se ho capito bene i vla finiscono sullo stack e non sullo heap....


Ti metto in evidenza la parte di creazione della matrice:
.........
/* modificato e semplificato per una matrice di 'int' */
int nCols = 10, nRows = 20;
int (*paMatrix)[nCols] = NULL; /* puntatore ad un array di nCols 'int' */
if(!(paMatrix = calloc(nRows, sizeof(*paMatrix))))
	return EXIT_FAILURE;
paMatrix[1][1] = 1;
paMatrix[2][2] = 2;
paMatrix[3][3] = 3;
paMatrix[4][4] = 4;
......
Ora, secondo te, paMatrix e' allocata sullo stack??
Sullo stack ci va a finire solo il puntatore paMatrix (4 bytes sul tuo 
Linux?)


 Linux?)
ma una doba del tipo
void funzione (int righe, int colonne) {
  int matrice[righe][colonne];
}
dove va?

 dove va?
Scusa: ma che c'azzecca? (cit.)
L'ho scritta io nell'esempio una cosa del genere...?


 permettano di capire se è questo il problema?
Con gdb risali alla linea che causa il crash, e puoi controllare i
parametri e le variabili di tutte le funzioni chiamanti. Va da se che
anche il puntatore di stack e' accessibile (esp se sei su IA32). 
-- 
Legrandin