[C++]GOTO invisibili?

[Tommo]

Salve,
a seguito di un refactoring per estendere il controllo degli script sul mio gioco, è uscito fuori un problema assurdo :mbe:
E' una cosa veramente incomprensibile... meglio spiegarsi con pseudocodice.



...
//chiedo alla Trace disegnata dall'utente di capire che tipo di oggetto rappresenta.
//Viene quindi restituito un InkObject astratto, in realtà contenente una sottoclasse.
0-InkObject* o = trace->recognizeShape();

6-altro
...

Trace::recognizeShape()
{
1-parse della traccia, con costruzione dei lod, delle dimensioni e la rimozione
dei punti superflui;

2-primo check preliminare chiamando gli script definiti dall'utente (un for)

3-malloc delle direzioni;

4-veramente tanta altra roba;

5-return della factory necessaria alla forma riconosciuta
}


Ora, l'insensatezza nasce nell'ordine in cui questo è eseguito (evidenziati i "goto invisibili", attenzione ai numeri):

0, 1, 2, 0, 1, 2, 3, 4, 5, 6, 3, 4, 5, 1, 2, crash.
Chiamando recognizeShape una sola volta... da notare anche il passaggio dal 6, dopo aver finito l'istruzione, al malloc come se ci fosse un goto che io certamente non ho messo.

Alla fine di questa assurdità, recognizeShape viene eseguito ancora una volta, ma il Trace che lo esegue diventa pieno di valori garbage; ma tuttavia non è null pointer.

E' la roba più strana che mi sia capitata nella mia seppurbreve carriera :mc:
Please Help!1!!1!

[marco.r]

la prima cosa che mi viene in mente e' che da qualche parte scrivi su sulla memoria sbagliata (e.g. sfori un array), andando a rovinare qualche puntatore nell'heap o nello stack.
Pero' bisogna vedere un po' piu' nel dettaglio come e' implementata quella sequenza di chiamate.

[banryu79]

bella gatta da pelare :eek:

[marco.r]

Una prima prova che puoi fare e' lanciare il programma con valgrind e vedere se (anzi, quando :D) comincia a segnalarti errori.

[71104]

sembrano essere due sequenze interleaved: secondo me stai eseguendo la stessa cosa contemporaneamente su due thread diversi.
edit - anzi, su più threads: poco dopo la partenza del terzo crasha.

[71104]

ecco secondo me quello che avviene:

sequenza principale: 0, 1, 2, 0, 1, 2, 3, 4, 5, 6, 3, 4, 5, 1, 2, crash.
primo thread: 0, 1, 2, 3, 4, 5, 6,
secondo thread: 0, 1, 2, 3, 4, 5,
terzo thread: 1, 2,

[71104]

la prima cosa che mi viene in mente e' che da qualche parte scrivi su sulla memoria sbagliata (e.g. sfori un array), andando a rovinare qualche puntatore nell'heap o nello stack. è praticamente impossibile rovinare dei puntatori sovrascrivendoli esattamente con quelli che farebbero andare a finire il flusso di esecuzione in punti del codice del programma, e perdipiù in punti così vicini (e così ben ordinati :sofico: ).

molto più probabile la mia ipotesi :Prrr:

[Tommo]

la prima cosa che mi viene in mente e' che da qualche parte scrivi su sulla memoria sbagliata (e.g. sfori un array), andando a rovinare qualche puntatore nell'heap o nello stack.
Pero' bisogna vedere un po' piu' nel dettaglio come e' implementata quella sequenza di chiamate. Una prima prova che puoi fare e' lanciare il programma con valgrind e vedere se (anzi, quando :D) comincia a segnalarti errori.

hmm è venuto in mente anche a me, ma dato che non ho scritto nulla che allochi memoria, non saprei davvero cosa può essere a farlo.
In più è implausibile perchè la sequenza è ESATTAMENTE questa, non cambia mai.
Invece sovrascrivendo memoria casuale dovrebbe dare ogni volta un errore diverso, anzi probabilmente crasherebbe e basta.

PS: che è valgrind, che lo provo? :D

ecco secondo me quello che avviene:

sequenza principale: 0, 1, 2, 0, 1, 2, 3, 4, 5, 6, 3, 4, 5, 1, 2, crash.
primo thread: 0, 1, 2, 3, 4, 5, 6,
secondo thread: 0, 1, 2, 3, 4, 5,
terzo thread: 1, 2,


Credo che tu ci abbia preso :doh:
La funzione infatti viene chiamata da Lua, e quando la chiamavo in C++ non aveva questo problema.
Magari si verifica una desincronizzazione che porta a chiamate multiple?
Anche questo cmq è strano, dato che sapevo che Lua non aveva un suo Thread se non si specifica diversamente.
Meglio controllare la sincronia... :stordita:

Cmq ho vinto il mongolino d'oro come autore del bug più oscuro, contorto e senza motivo :asd:

[Tommo]

Hmm... ho messo una pezza mettendo un Bool nella classe, che impedisce due esecuzioni contemporanee del metodo... funziona, ma è bruttone... e non impedisce che riaccada altrove.

Cmq ho appurato che il Lua chiama 2 volte la funzione wrapper, sebbene ci sia una sola chiamata; e che se levo quest'unica chiamata la funzione wrapper è attivata una volta sola, ma poi il metodo non arriva alla fine. Chissà dove altro lo chiama :stordita:

Che schifo :D

[marco.r]

è praticamente impossibile rovinare dei puntatori sovrascrivendoli esattamente con quelli che farebbero andare a finire il flusso di esecuzione in punti del codice del programma, e perdipiù in punti così vicini (e così ben ordinati :sofico: ).

molto più probabile la mia ipotesi :Prrr:

Niente e' impossibile se si va a sovrascrivere la memoria :asd:, soprattuto tipicamente l'errore appare dove non l'hai commesso. Mi e' capitato di vedere cose simili. Visto che non aveva parlato di piu' thread avevo escluso l'eventualita' che hai esposto.

[marco.r]

Hmm... ho messo una pezza mettendo un Bool nella classe, che impedisce due esecuzioni contemporanee del metodo... funziona, ma è bruttone... e non impedisce che riaccada altrove.

Cmq ho appurato che il Lua chiama 2 volte la funzione wrapper, sebbene ci sia una sola chiamata; e che se levo quest'unica chiamata la funzione wrapper è attivata una volta sola, ma poi il metodo non arriva alla fine. Chissà dove altro lo chiama :stordita:

Che schifo :D
Uhm, ma in pratica quanti thread ha il tuo programma che gira ? O li elimini del tutto o ti conviene rendere il metodo thread-safe (no alterazione di variabili di istanza), se possibile ovviamente.

[Tommo]

La mia applicazione ha 3-4 threads:
-Ogre+logica di gioco
-PhysX
-Lua
-Ogni tanto caricamento delle risorse.

Il thread incriminato è quello del Lua... tuttavia, dato che non lo creo io, e dato che ci comunico tramite uno Stack non gestito da me, non vedo come faccia ad andare fuori sincrono... in tutte le altre occasioni funziona alla perfezione.

Cmq, analizzando meglio il problema, ho notato che esiste un "eco" di chiamata da Lua: la funzione wrapper viene chiamata due volte di seguito, e fra l'altro la seconda chiamata a distanza di millisecondi non funziona... cioè, se tolgo la prima, la seconda non ha alcun effetto.

Sto ancora cercando un'altro KeyListener, che magari continua a chiamare il metodo incriminato, ma non sembra ci sia... non capisco veramente da dove arriva la "chiamata fantasma" :mbe:

Cmq per rendere il metodo thread safe in maniera rozza ho fatto così:

--membri della classe
bool buildingBusy;

--costruttore
buildingBusy = false;

--endDrawing (il metodo chiamato 2 volte)
if( buildingBusy ) return NULL;
else buildinBusy = true;
...
buildingBusy = false;
return o;


Come ho detto prima funziona, ma non mi soddisfa. Questa discrepanza ha l'aria di nascondere un problema ben più "cattivo"... quindi è meglio trovarlo da subito.

[Tommo]

Trovato il problema di fondo... ma non riesco lo stesso a risolverlo :doh:

In pratica, quando si finisce di disegnare una forma, questa viene sottoposta o al custom match dell'utente, o al riconoscimento con gli angoli + un post match dell'utente.

Tuttavia, la prima funzione di match che viene eseguita non viene trovata (anche se sicuramente esiste); tutte le volte che viene rieseguita invece viene trovata ma non restituisce un bool.
Quindi deduco che per qualche motivo i pointers alle funzioni vengono modificati, anche se non so come o perchè :muro:

Cmq se disattivo del tutto gli user matches il problema originale del topic non si presenta più, anzi funziona tutto bene...

Qualche idea? :mc: