C++

perte d'adresses à l'appel d'une fonction

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : perte d'adresses à l'appel d'une fonction

zbouirf

poukram et dre dans le pentu

Bonjour,

Je développe une application multi thread. Pour cela j'utilise la version win 32 des threads POSIX.
La fonction permettant de creer un thread a la signature suivante :

Code :

int pthread_create(pthread_t * thread, pthread_attr_t * attr, void * (*start_routine)(void *), void * arg);

Ou le dernier argument "arg" est un pointeur donné en parametre a la fonction "start_routine" qui est appelée au lancement du thread.
Dans mon implementation, ma fonction "start_routine" caste ce pointeur pour le transformer en un pointeur sur une structure contenant tous les
parametres dont j'ai reellement besoin :

Code :

struct ExecutionData
{
PipelineModule* pm;
PipelineData* data;
sem_t* lock;
};
void* launchExecute (void* data)
{
ExecutionData* ed2 = static_cast<ExecutionData*>(data);
ed2->pm->execute (ed2->data); // ERREUR, Access violation reading location 0x00000000
sem_post (ed2->lock);
return NULL;
}

Et voici comment j'appelle la fonction lancant le thread :

Code :

...
ExecutionData* ed1 = new ExecutionData ();
ed1->pm = this;
ed1->data = data;
ed1->lock = lock;
pthread_t thread;
sem_wait (lock);
pthread_create (&thread, NULL, &launchExecute, ed1);
...

Lorsque le programme arrive à la ligne (dans la fonction "launchExecute" )

Code :

ed->pm->execute (ed2->data);

, l'erreur "Access violation reading location 0x00000000" est levée.
Lorsque je pose un breakpoint avant le lancement du thread, "ed1" contient les bonnes valeurs ! C'est à dire que les 3 pointeurs contenus dans "ed1" ont une valeur coherente:
ed1 = 0x003a6528
ed1->pm = 0x003a63b0
ed1->data = 0x003a6328

Lorsque je pose un breakpoint juste avant le caste dans "launchExecute", data contient la bonne adresse ! C'est à dire la même adresse que "ed1" avant le lancement du thread :
data = ed2 = 0x003a6528

Or après le caste, "ed2" contient toujours la bonne valeur mais son contenu a été écrasé ! les adresses sont :
ed2 = 0x003a6528
ed2->pm = 0x0000
ed2->data = 0x0000
ed2->lock = 0x0000

Je ne vois pas comment faire pour récupérer les données dont j'ai besoin !
Ou est l'erreur ?
Quelles seraient les alternatives ?

Merci d'avance pour vos reponses !

Publicité

Taz

bisounours-codeur

#
ExecutionData* ed1 = new ExecutionData ();
#
ed1->pm = this;

c'est qui this la ?

zbouirf

poukram et dre dans le pentu

C'est le pointeur sur l'objet qui lance le thread.
Cet objet contient une methode virtuelle pure "execute (PipelineData* pm)". Celle qui est appelée par la fonction "launchExecute" :
ed2->pm->execute (ed2->data);

Mais ceci ne change pas grand chose, ce qui est vraiment surprenant, c'est que ma structure est déclarée en memoire centrale, pas sur la pile, tant qu'aucun delete n'est effectué, la memoire ne devrait pas revenir a zero !

Message édité par zbouirf le 31-07-2007 à 11:58:23

kirua_sama

Learn sciences with senses

La réponse s'il vous plais

---------------
“L'éducation est l'arme la plus puissante que l'on puisse utiliser pour changer le monde”

Taz

bisounours-codeur

Y en a pas, c'est un bug spécifique au code de zbouirf, y a des milliards de pthread qui tourne tous les jours sans problème.

kirua_sama

Learn sciences with senses

Merci.

---------------
“L'éducation est l'arme la plus puissante que l'on puisse utiliser pour changer le monde”

FORUM HardWare.fr

Programmation

C++

perte d'adresses à l'appel d'une fonction

Sujets relatifs
probleme caractere (fonction mail)	Fusion de 2 scripts pour une fonction précise
Appel de commande Windows( system !) en C++	Modification d'une fonction pour selectionner une plage de cellule
petit souci avec une fonction simple	Excel macro pour appliquer fonction sur une colonne
Problème avec fonction IF NOT EXIST	Surcharge de l'opérateur = + Appel non souhaité à delete
VBA [Résolu] Passer une fonction en paramètre	appel d'une fonction (execution) qui est definie par un char[]
Plus de sujets relatifs à : perte d'adresses à l'appel d'une fonction

Page générée en 0.039 secondes