[MFC] Thread terminé brutalement

**OjBarbare** · 15/02/2006, 17h17

Bonjour

Je developpe une appli avec vc++ 6, en me servant des MFC notament pour créer des threads. Mon souci est que l'appli est brutalement quitté à des moment aléatoires (de mon point de vue), et ce meme en mode débug qui ne me fournit aucune info, la seule info qu'il me donne c'est que les threads du programme ont terminé avec le code 0, et parfois le code 3.

Si vous avez la moindre piste, parlez m'en!
Merci

mat.M · 15/02/2006, 17h18

Envoyé par OjBarbare

Bonjour

Je developpe une appli avec vc++ 6, en me servant des MFC notament pour créer des threads. Mon souci est que l'appli est brutalement quitté à des moment aléatoires (de mon point de vue), et ce meme en mode débug qui ne me fournit aucune info, la seule info qu'il me donne c'est que les threads du programme ont terminé avec le code 0, et parfois le code 3.

Si vous avez la moindre piste, parlez m'en!
Merci

Nous non plus on ne peut pas avoir plus de pistes!
Sans code difficile à dire.
Le mieux est d'utiliser la macro TRACE des MFC qui permet de faire un diagnostic

**OjBarbare** · 15/02/2006, 17h43

le code est basique en ce qui concerne la création du thread :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AfxBeginThread((AFX_THREADPROC)reception,GetSafeHwnd()

tu peux m'en dire un peu plus sur TRACE steuplé

merci

ps : javai trouvé ya qq temps un pti tuto sur le debuggeur VC, avec la signification de certaines valeur type.... je ne trouve plus... si qq'un voit de quoi je parle, ce serait cool de me dire ou ça se trouve

[edit] je lai retrouvé, pour ceux que ça interresse : ftp://ftp-developpez.com/farscape/tutoriels/demarrer-mfc-vc6.pdf

**OjBarbare** · 16/02/2006, 11h23

visiblement personne n'est inspiré...
qq'un connnaitrait-il la signification des code de sortis? je suppose que 0 est la terminaison "normal" du thread... mais pour le reste???

**Caine** · 16/02/2006, 11h40

Pour les autres codes va dans l'aide de l'API windows.

As-tu essayé de faire tourner ton appli en "stubbant" le thread?

As-tu essayé en pas à pas pour voir l'état de la pile d'appel?

Un _try..._except dans ton thread voir le coeur de l'appli t'aidera peut-être à comprendre.

**Médinoc** · 16/02/2006, 13h15

Es-tu sûr que ta procédure de thread possède le bon en-tête ?

Quand il y a un cast, c'est généralement que ce n'est pas le cas...

**ienien** · 16/02/2006, 13h16

Salut!
Pourquoi ne pas détecter la fin de ton appli, et fermer tes threads manuellement à ce moment là?

**OjBarbare** · 16/02/2006, 14h28

Envoyé par Caine

As-tu essayé de faire tourner ton appli en "stubbant" le thread?
As-tu essayé en pas à pas pour voir l'état de la pile d'appel?

je ne connais pa la technique du "stubb"...

Pour ce qui est du pas à pas, mes thread etant plutot du genre conséquent, et le probleme survenant aléatoirement je pense que jaurai du mal à détecter qqchose (l'appli tourne défois 2h sans planter...), mais jvè essayer qd meme

Pour ce qui est du cast, ma fonction est bien de type (AFX_THREADPROC) , mais si je ne le met pas, voila le msg :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error C2665: 'AfxBeginThread' : none of the 2 overloads can convert parameter 1 from type 'unsigned int (__cdecl *(__cdecl *)(void *))(void *)'

Envoyé par ienien

Pourquoi ne pas détecter la fin de ton appli, et fermer tes threads manuellement à ce moment là?

Le souci c'est que tous mes threads sont fermés sans que je le veuille... j'avais penser mettre une boite de dialogue demandant si on veut effectivement fermer, mai meme si ça marche ça ne peut pas etre une solution durable...

mat.M · 16/02/2006, 15h10

La Macro TRACE permet dans la fenêtre de déboguage de VC++ d'afficher en exécution des CString comportant des messages.
Donc lors de l'appel de AfxBeginThread, tu peux placer un TRACE pour avoir l'état des variables locales .

Le souci c'est que tous mes threads sont fermés sans que je le veuille... j'avais penser mettre une boite de dialogue demandant si on veut effectivement fermer, mai meme si ça marche ça ne peut pas etre une solution durable...

:
C;est que le Thread se déroule correctement.
Un Thread c'est un mini programme en parallèle.

**OjBarbare** · 16/02/2006, 15h15

Envoyé par mat.M

C;est que le Thread se déroule correctement.

justement, d'ou mon probleme... il ne devrait pa se fermer... ou tout du moins, meme si un thread que jai créé se ferme, il ne devrait pas entrainer la fin de toute l'appli...

**ienien** · 16/02/2006, 16h20

Peux-tu déposer sur le forum un minimum de code pour que l'on puisse comprendre ce qui se passe...
D'après ce que tu écris, je pense qu'il y a bug sous roche qui fait planter ton appli, et donc tes threads.
As-tu des variables auxquelles accèdent tes threads et qui "débordent"?
Gères-tu l'accès par plusieurs threads à une même variable?
Courage...

**OjBarbare** · 16/02/2006, 18h23

jaimerai bien, mai le code est vraiment grand... et chaque thread accede a differents fichiers.... (en fait je ne crée qu'un seul thread qui tourne en permanence)
pour ce qui est des débordement de variable, je pense que le debuggeur les reconnaitrait avant de fermer l'appli...
Le thread que je crée accede bien a une variable partagée, mais seulement en lecture (et appel de fct), donc a priori pas de section critique

a force de fouiller jvè ptete trouver!

**Caine** · 16/02/2006, 21h20

Les débrodements de variable sont vérifier si l'otpion est activée dans les options de projets.

Vérifie aussi que le projet s'arrète sur toutes les exceptions.

**Médinoc** · 17/02/2006, 00h16

Envoyé par OjBarbare

Pour ce qui est du cast, ma fonction est bien de type (AFX_THREADPROC) , mais si je ne le met pas, voila le msg :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

error C2665: 'AfxBeginThread' : none of the 2 overloads can convert parameter 1 from type 'unsigned int (__cdecl *(__cdecl *)(void *))(void *)'

Dis-moi, tu n'aurais pas par hasard fait la c***erie suivante ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AFX_THREADPROC reception(void *);

Si c'est le cas, tu nous as déclaré une fonction RETOURNANT une AFX_THREADPROC. (Ta fonction se retrouve du type 'unsigned int (__cdecl *(__cdecl *)(void *))(void *)' qui ne correspond PAS à une AFX_THREADPROC)

Tu dois déclarer ta fontion ainsi:

Envoyé par MSDN : AfxBeginThread()

UINT MyControllingFunction( LPVOID pParam );

Là, ta fonction sera bien du type 'unsigned int (__cdecl *)(void *)' qui correspond bien au type AFX_THREADPROC.

**Caine** · 17/02/2006, 08h37

Sans vouloir pinailler, il y a erreur dans ton quote, ce n'est pas moi qui ai écris ça

**OjBarbare** · 17/02/2006, 11h46

mes threads sont déclarés comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AFX_THREADPROC reception(LPVOID lpParam);

jai fait la moitié de la connerie... vè changer ça de ce pas

ps : je trouve pas ou config le projet pour gerer les débordements de mem... c'est bien dans "Project Settings"?

**Caine** · 17/02/2006, 13h26

Autant pour moi, j'ai confondu avec Delphi. Je ne suis pas sûr que ça existe avec VC

**Médinoc** · 17/02/2006, 15h52

Caine : Corrigé.

OjBarbare: En fait, tu a fait toute la connerie : Il n'y a pas d'autre moitié.

**OjBarbare** · 18/02/2006, 13h15

ok lol
mais tu penses que ça pourrai venir de là???

**farscape** · 18/02/2006, 18h27

Je prends un peu le sujet en route, apparemment tu utilises des fichiers ou autres ressources dans tes threads tu traites les exceptions d'erreurs ?
quels types d’apis tu utilises pour la gestion des fichiers : le c , les stl , ou avec les MFC ?
si tu lances ton programme en debug ça plante ?
si ça sort du programme de la même manière tu as regardé dans la fenêtre du debug trace si il n'y avait pas de notification d'erreurs ?

[MFC] Thread terminé brutalement

MFC

Discussions similaires

Partager

Partager