Version imprimable
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!Citation:
Envoyé par OjBarbare
Sans code difficile à dire.
Le mieux est d'utiliser la macro TRACE des MFC qui permet de faire un diagnostic
le code est basique en ce qui concerne la création du thread :
tu peux m'en dire un peu plus sur TRACE steuplé :)Code:AfxBeginThread((AFX_THREADPROC)reception,GetSafeHwnd()
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
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???
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.
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...
Salut!
Pourquoi ne pas détecter la fin de ton appli, et fermer tes threads manuellement à ce moment là?
je ne connais pa la technique du "stubb"... :oops:Citation:
Envoyé par Caine
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:error C2665: 'AfxBeginThread' : none of the 2 overloads can convert parameter 1 from type 'unsigned int (__cdecl *(__cdecl *)(void *))(void *)'
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...Citation:
Envoyé par ienien
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 .
Citation:
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.
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...Citation:
Envoyé par mat.M
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... :)
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! :)
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.
Dis-moi, tu n'aurais pas par hasard fait la c***erie suivante ?Citation:
Envoyé par OjBarbare
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)Code:AFX_THREADPROC reception(void *);
Tu dois déclarer ta fontion ainsi:Là, ta fonction sera bien du type 'unsigned int (__cdecl *)(void *)' qui correspond bien au type AFX_THREADPROC.Citation:
Envoyé par MSDN : AfxBeginThread()
Sans vouloir pinailler, il y a erreur dans ton quote, ce n'est pas moi qui ai écris ça :twisted:
mes threads sont déclarés comme ça :jai fait la moitié de la connerie... vè changer ça de ce pasCode:AFX_THREADPROC reception(LPVOID lpParam);
ps : je trouve pas ou config le projet pour gerer les débordements de mem... c'est bien dans "Project Settings"?
Autant pour moi, j'ai confondu avec Delphi. Je ne suis pas sûr que ça existe avec VC :(
Caine : Corrigé.
OjBarbare: En fait, tu a fait toute la connerie : Il n'y a pas d'autre moitié. ;)
ok lol
mais tu penses que ça pourrai venir de là???
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 ?
:D
non je ne traite pas les exceptions d'erreur... c'est vrai que je ferai bien d'aller fair un tour par là :oops:
sinon je comprends pas trop ce que tu veux dire par "API pour la gestion des fichiers"..... je fais des #include. mais ptete que tu parles pas de ce genre de fichier... le seul fichier externe que jutilise est zlib1.dll
et pour revenir au debug, ça "plante" de la meme maniere qu'en release, et vu que c'est pas vraiment un plantage (les threads se terminent plus ou moins "normalement"), ben le debuggeur me donne aucune trace... :cry:
un exception d'erreur sur un fichier peut fermer ton programme ...
si tu utilises la lib de compression j'irai voir de ce coté la aussi pour la gestion des erreurs...
en debug le programme s'arrete net ou tu as la main sur l'assertion d'erreur ?
:D
non non meme en debug ça sarrete net... avec 0 ou 3 en code de sortie
merci pour les conseils :)
Bonjour,
Utilises ce qui suit pour connaître le texte associé au code erreur:
Attention, je suis sur EVC, mais je pense que ça existe aussi sous VC.Code:
2
ça, je ne sais pas, mais sous VC++, il y a ::FormatMessage()
(Attention, CString::FormatMessage() ne marche pas pour les messages d'erreurs. Pas directement, en tout cas).