[C] Pazzesco! Istruzione successiva manda in errore la precedente!!MA COME?!

[parisisalvo]

Salve!!
Io programmo da una decina d'anni, e una cosa del genere non mi era mai successa.
Ecco lo scenario :

double div; //globale

main {

div=xxxx.yy; (un valore qualsisasi)
... creo socket datagram
... creo thread che gestisce il socket
}

void* thread(void* s)
{
unsigned long long cl;
 s è il descrittore del socket
 n=recv(s, ... ... ... ); 
 rdtscll(cl);
 cl/=div;
}

Allora, su UNA delle mie 3 macchine cosa accade :
che se nel codice lascio cl/=div; la recv va sempre in errore ancora prima che venga eseguita la divisione!!!! Mi torna in n il valore -1 !!!
Ossia :
n=recv(s, ... ... ... );
printf("%d\n",n); ---> a schermo stampera' -1
rdtscll(cl);
cl/=div;

Se invece al posto di cl/=div, metto cl=cl/(unsigned long long)div; tutto funziona!! Ossia in n ho il numero di byte giusti!
Il bello è che, in un'altra versione dello stesso codice, la recv funziona con la divisione sottostante...

La domanda è : Come CAVOLO fa una istruzione non ancora eseguita a far andare in errore quella precedente????????

[cionci]

A me mi puzza di buffer overflow...

[jappilas]

che macchina (nel senso, che cpu) è quella su cui ti si presenta l' errore?

mi vien l' impressione che sia un problema di pipeline e modo in cui la specifica macchina gestisce le eccezioni al proprio interno (che giusto per complicare un po' le cose , varia da un processore all' altro)...

[parisisalvo]

Nel portatile con Centrino M740 non va, invece nel Centrino M725 tutto ok, posso eseguirlo sia in un modo e a maggior ragione nell'altro.
Sia su un XP 2600+ che su vecchiotto Athlon 1Ghz, funziona come nell'M725...

[Black imp]

Originariamente inviato da parisisalvo

Salve!!
Io programmo da una decina d'anni, e una cosa del genere non mi era mai successa.
Ecco lo scenario :

double div; //globale

main {

div=xxxx.yy; (un valore qualsisasi)
... creo socket datagram
... creo thread che gestisce il socket
}

void* thread(void* s)
{
unsigned long long cl;
 s è il descrittore del socket
 n=recv(s, ... ... ... ); 
 rdtscll(cl);
 cl/=div;
}

Allora, su UNA delle mie 3 macchine cosa accade :
che se nel codice lascio cl/=div; la recv va sempre in errore ancora prima che venga eseguita la divisione!!!! Mi torna in n il valore -1 !!!
Ossia :
n=recv(s, ... ... ... );
printf("%d\n",n); ---> a schermo stampera' -1
rdtscll(cl);
cl/=div;

Se invece al posto di cl/=div, metto cl=cl/(unsigned long long)div; tutto funziona!! Ossia in n ho il numero di byte giusti!
Il bello è che, in un'altra versione dello stesso codice, la recv funziona con la divisione sottostante...

La domanda è : Come CAVOLO fa una istruzione non ancora eseguita a far andare in errore quella precedente????????

scusa ma tu gestisci una variabile condivisa tra due thread - il main e quello legato al socket - senza un semaforo?
per me il problema è quello

[cionci]

Originariamente inviato da Black imp

scusa ma tu gestisci una variabile condivisa tra due thread - il main e quello legato al socket - senza un semaforo?

Se ci accede anche dopo la creazione del thread potrebbe essere anche quello...

[parisisalvo]

l'unica variabile condivisa è il descrittore del socket s...
questo numero non viene mai toccato...
io cmq, ne faccio una copia dentro il thread
con : int *socket=(int*)s;
cmq, nel main quel descrittore non viene usato, resta tale, finche non si chiude il main. Dopo aver creato il socket, il descrittore del socket nel main, nn viene toccato...il main poi resta vivo con un semplice while(1);
Tant'è vero che CODICE identicissimo, tranne che per la divisione, funziona PERFETTAMENTE.
Forse ho un po' troppo semplificato il codice...piu' realisticamente è cosi' :

double div; //globale

main {
int sk; //locale al main
div=xxxx.yy; (un valore qualsisasi)
... creo socket datagram -> sk;
... creo thread che gestisce il socket gli passo (void*)&sk
while(1);
}

void* thread(void* s)
{
 int *sock=(int*)s;
 int socket=*sock;
 int n; 
 unsigned long long cl;
 socket è il descrittore del socket
 n=recv(socket, ... ... ... ); 
 printf("Socket ha ricevuto %d byte\n",n);
 rdtscll(cl);
 cl/=div;
}

Per debug, ho messo un printf subito dopo la recv, ossia
printf("Socket ha ricevuto %d byte\n",n);
La printf è messa PRIMA della divisione di cl.
Se lascio la divisione (ossia, tre righe di codice dopo), la recv, andra' in errore, e la printf stampera' -1, se faccio la divisione "per esteso" stampera' 20 (il numero di byte, che effettivamente l'altro calcolatore invia).
La cosa che non mi capacita è :
Come fa la recv ad andare in errore per una istruzione non ancora eseguita???
La divisione, viene poi effettuata correttamente, ma la recv non funziona!!
Vi giuro, se cambio solamente cl/=div con cl=cl/(unsigned long long)div; la recv funziona, e come byte stampa 20.

[jappilas]

quello che mi fa strano e a cui sto ancora cercando un senso logico, è che su due macchine su tre non ti dia errori e sulla terza sì... o_O

[parisisalvo]

Ancora peggio!!!
Con l'amico mio, per cercare di risolvere abbiamo passato due ore...
a testare e provare linea per linea...
chi l'avrebbe mai detto che era una divisione???
La cosa ancora piu' assurda, è che essendo un progetto molto grosso, ha tante "relase", ogni settimana apportiamo delle migliorie, parti nuove ect ect, fino all'altro ieri, funzionava tutto perfetto (anke sul M740). Ossia Recv con successiva divisione cl/=divclock.
Ma la cosa ancor piu' strana è che solo una macchina presenta il problema!!!
Ossia non è un errore "oggettivo", ma soggettivo...
immaginate la mia crisi di nervi, come faccio a correggere un errore che non c'e'???? è da diventar matti! Su 3 macchine funziona, e sull'altra no. Come correggo un errore che in teoria, solo la mia "vede".
Dopo due orette, a testare linee di codice, e provare...abbiamo visto che era la maledettissima divisione!!!

[Black imp]

quando compilo sotto linux con più thread o addirittura processi mi capita che le print non vengano eseguite subito ma a volte ritardate.

se poi compili con qualche ottimizzazione può essere che una operazione venga svolta in un momento diverso da quello che ti aspetti. per questo ti dicevo di usare dei semafori. la var condivisa era div.

[71104]

secondo me si tratta di una race condition: forse il codice generato per l'operatore /= differisce da quello generato per = e / separati; controlla l'assembly generato dal tuo compilatore (a proposito, quale usi?).

[parisisalvo]

uso il gcc...
pero', compiliamo sempre su una sola macchina (dove abbiamo installato tutte le librerie) poi passiamo i files alle altre 3 (tra cui l'M740).

[71104]

Originariamente inviato da parisisalvo

uso il gcc...
pero', compiliamo sempre su una sola macchina (dove abbiamo installato tutte le librerie) poi passiamo i files alle altre 3 (tra cui l'M740).

ad ogni modo è impossibile che il gcc compili differentemente su macchine diverse; intendevo dire che per capire la causa dovresti analizzare il codice assembly generato dal compilatore nei due diversi casi (è l'unica cosa che fa la differenza tra le due versioni del programma); molto probabilmente concluderai che si tratta di una race condition.
inoltre, lascia perdere questo fatto della divisione: cerca la causa del problema in maniera "standard"; in maniera "standard" se la recv ti restituisce -1 e tu non capisci perché, devi semplicemente chiamare WSAGetLastError (sempre che usi Winsock 2 su Windows, altrimenti non lo so).

[cionci]

Originariamente inviato da parisisalvo

uso il gcc...
pero', compiliamo sempre su una sola macchina (dove abbiamo installato tutte le librerie) poi passiamo i files alle altre 3 (tra cui l'M740).

Hai provato a ricompilare sulla macchina che presenta il problema ?

[71104]

Originariamente inviato da cionci

Hai provato a ricompilare sulla macchina che presenta il problema ?

secondo me non cambia nulla... e se cambiasse qualcosa mi preoccuperei davvero O_O

[parisisalvo]

Ora è ancora piu' grave!!!
Abbiamo fatto un "upgrade" del software...
mettendo quello che quella maledetta recv riceve in un vettore...
chissà per quale maledetto motivo, torna lo stramaledetto -1
Ovviamente SOLO sulla macchina M740!
L'applicazione è fatta con le GTK, le altre macchine hanno su la SuSe 9.3 l'M740 ha la Fedora Core 4. L'M740 è un Acer1692 e non ho potuto installare suse, solo fedora è stata la piu' compatibile (wireless card e s.video).
Voi che dite? puo' essere colpa della distro??

(Se dal codice rimuovo tutta la parte gtk, l'applicativo funziona sempre, inserendo la parte gtk, funziona con le particolarità).

[Qu@ker]

Ma a quale errore si riferisce quel -1? Valore di errno?

[71104]

Originariamente inviato da parisisalvo

(Se dal codice rimuovo tutta la parte gtk, l'applicativo funziona sempre, inserendo la parte gtk, funziona con le particolarità).

in altre parole se ci rimuovi una parte che non c'entra niente funziona: è sicuramente race condition. ribadisco il consiglio di Quaker: errno?

[cionci]

Originariamente inviato da cionci

Hai provato a ricompilare sulla macchina che presenta il problema ?

Ribadisco...

[parisisalvo]

sulla macchina M740, non ci sono le lib grafiche...sulla Suse si sn installate in un secondo qua' richiede cose che gia' sono installate (tipo pango atk gdlib) arrivate alla gtk mi da errore, ho provato a installare quelle di fedora native, ma è come se non ci fossero, appena do make, mi da errore su tutta la grafica...quindi per compilare devo eliminare la parte gtk, e quindi funziona.

Dite di inserire l'istruzione

n=recv(... ... ...)
if (n<0) perror(" Errore : ");