Discussion :

[Gulish]

Salut,

Je développe depuis quelques temps le même logiciel, et j'ai déjà fait plusieurs release, que j'ai exportées en joignant les dlls nécessaire à son éxécution. Tout marchait bien.

J'ai depuis fait une update, en ajoutant des éléments qwt, et en passant à Qt443, et là, un gros mystère :

Lorsque je compile, en debug comme en release, aucun problème.
Lorsque j'éxécute, en debug comme en release, à travers VS express 2008, aucun problème.

Lorsque j'éxécute mon appli en la lançant depuis l'explorateur de fichier, en allant dans mon dossier release, l'appli se lance, et lorsque je tente d'activer un nouveau thread, il me met une erreur de de type pointeur null (voir pj).

J'ai essayé d'ajouter toutes les dlls possibles, rien à faire. A mon avis, ça provient du changement de version de Qt, et peut être d'une gestion différente de Qt. Pour info, j'étais en Qt 440 avant (version open source pour les 2).

Si quelqu'un a une idée ... J'achète !

G.

[yan]

Salut,
Es tu sur de la version de Qt que tu utilise pour compiler?


essaie de copier les dll de Qt à coté de ton exe
et les fichiers situés
C:\Program Files\Microsoft Visual Studio x\VC\redist\x86\Microsoft.VCxx.CRT

pour voire ce qui se passe.

[Gulish]

Es tu sur de la version de Qt que tu utilise pour compiler?

J'ai viré l'autre, donc oui !

essaie de copier les dll de Qt à coté de ton exe
et les fichiers situés
C:\Program Files\Microsoft Visual Studio x\VC\redist\x86\Microsoft.VCxx.CRT

C'est ce que je fais normalement pour exporter, mais encore fois, ça ne marche pas. L'appli se lance, je peux afficher mes widgets, les déplacer, tout va bien. Le programme plante juste quand j'éxécute mon Thread, quand j'appelle le run().

Pourtant, je n'ai pas touché cette partie là, et le code fonctionne sous VS... Le plus fou, c'est que lorsque je lance la version debug avec l'explorateur de fichier, elle marche...

Comprends pas ... Toutes les DLLs ont l'air présentes et accessibles ...

G.

PS : voici la pièce jointe oublié dans le premier post (message d'erreur)

[MacPro]

salut, est-ce que tu es sûr d'avoir tout recompilé avec nmake, et de ne pas avoir laissé des dll compilées avec mingw ?
J'ai fait comme toi, je suis passé de 4.4.0 mingw, vers 4.4.1 Visual studio, puis 4.4.3 visual studio et je n'ai aucun problème, chaque fois j'ai tout recompilé avec Visual.
D'ailleurs, j'ai tout refait proprement ce matin.
Donc si ça t'intéresse, je peux te filer les dll qwt5.dll, qwt5d.dll, qwt5_plugin_designer.dll, et d'autres (compilées avec visual, Qt 4.4.3).
Parfois, on a oublié une variable d'environnement oboslète aussi, donc le mieux, et de mettre l'application dans un dossier avec toutes ses dll nécessaires, histoire d'être sûr que le système n'aille pas chercher des dlls qui ne conviennent pas.

[yan]

Quelques idées plus ou moins pertinente...

As tu essayer de faire un clean et un rebuilt?

(ça fait pas de mal)

As tu vérifié que tu n'as pas un message sur la console?

T'aurais pas créé des objets dans ta thread en passant this comme parent?

(Qthread n'appartient à la thread seul ce qui est créé dans le run en fait partie)

T'utiliserais pas un objet créé hors du run? comme dans le constructeur de ton QThread par exemple

(idem)

T'aurais pas un slot dans QThread qui utilise un objet créé dans le run?

(les slots du QThread sont exécutés dans la thread qui la créé en non dans la thread qui créé pour executer le run)

Est tu sur que tu protège les accès des données partagées entre thread?

(mutex, semaphore,...)

Est tu sur de tes pointeurs?

(je verais bien un truc ici)

Utilise tu des widgets dans cette thread?

(pas bien)

Passe tu des classes à toi en paramètre dles connet entre les threads?

(il faut que ces class soit copiable car le slot sera executé dans son thread)

[MacPro]

As tu essayé de faire un clean et un rebuild?

Moi j'irai plus loin, connaissant les déconvenues de l'intégration à Visual :
Choper tous les *.obj (qui ne sont pas tous supprimés bizarrement) et les supprimer manuellement parce que le clean il nettoie pas grand chose !

[Gulish]

Pour répondre à Kestufou, j'ai jamais utilisé mingw, toujours VS Express, certes plusieurs versions, mais ça fait un moment que j'utilise le 2008, et ça fait plusieurs fois que je change de versions de Qt sous VS Express 2008.
Donc de ce coté là, je suis rodé., et j'ai quand même vérifié 20 fois (ça fait 3 jours que je bloque dessus).
Mais merci pour ta proposition.

Pour repondre à Mongaulois, que je remercie pour ses pistes :
J'ai respecté la majorité des conseils sauf peut être :

T'aurais pas un slot dans QThread qui utilise un objet créé dans le run?

J'ai peut être instancié un tableau que je passe en argument d'un signal. Je vais vérifier. Mais en tout cas il marche, même s'il ne faut pas le faire.

Passe tu des classes à toi en paramètre dles connet entre les threads?

Oui, en faisant des qRegisterMetaType. Ca pose un problème ?

Merci en toutcas, je susi occupé ajd,

Je verrai plus tard.
G.

[yan]

J'ai respecté la majorité des conseils sauf peut être :

T'aurais pas un slot dans QThread qui utilise un objet créé dans le run?

J'ai peut être instancié un tableau que je passe en argument d'un signal. Je vais vérifier. Mais en tout cas il marche, même s'il ne faut pas le faire.

Ça tombe peut être en marche. C'est pas pareil Tout comme une erreur mémoire peut tomber en marche.
En debug ou en lançant une version release avec visual peut faire tomber un marche de tel problème, car visual borne l'execution.
Normalement lancer ton appli avec ctrl+F5 cela est sensé revenir au même que de le lancer de l'explorateur.

Passe tu des classes à toi en paramètre des connect entre les threads?

Oui, en faisant des qRegisterMetaType. Ca pose un problème ?

Si tu n'as pas implémenté le constructeur par recopie(il me semble que c'est celui là) c'est possible.

Une discutions par rapport à l'exemple de mandelbrot. J'y ai fait un exemple pour comprendre comment et quand sont copier les objet.
http://www.developpez.net/forums/d48...qt-mandelbrot/