[Qt4.4.3] Problème d'export d'application

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.

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.

Citation:

---

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

---

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

Citation:

---

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)

:oops: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.

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 :cfou: 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)

Citation:

---

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 !

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 :

Citation:

---

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.

Citation:

---

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.

Citation:

---

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

Citation:

---

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.

Citation:

---

Citation:

---

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/

Bon j'ai quand même déplacé l'instanciation de mes objets hors du run. Mais ça ne change rien.

Sinon, je ne connaissais pas le ctrl+F5, je faisais juste F5, et je retrouve la même erreur en mode release. Par contre le debug marche toujorus parfaitement ... Merci pour l'info.

Ca commence à me prendre le chou cette histoire. Je verrai ça demain.

G.

Citation:

---

Envoyé par Gulish

Bon j'ai quand même déplacé l'instanciation de mes objets hors du run. Mais ça ne change rien.

---

:koi:
t'as viré la thread?

Je vais me pendre !

Bon j'ai trouvé, un truc complètement con, mais je ne comprends pas pourquoi le compilateur merde comme ça. Pour résumer, parce ça serait trop long de tout expliquer, voici la situation :

Code:

---

1 2 3 4 5 6

nbLecture = max(nombre1,nombre2) //nombre1 et nombre2 étant des données modifiable par des slots   for(int i =0;i<nbLecture;i++) monVector[i]=monTableau[i];//monTableau a une taille de 512.   emit monSignal(monVector);

---

Cette séquence est répétée dans mon thread. Au départ, vu que l'utilisateur n'a pas forcément changé les valeurs de nombre1 et nombre 2, j'ai déclaré :

Code:

---

1 2	int nombre1 = 4; int nombre2;

---

Le problème c'est que nombre2 était initialisé à une valeur débile (du genre 1072103414), et donc ma boucle for() se faisait un paquet de fois, et je dépassais la capacité de monTableau au démarrage.

Le plus dingue, c'est que j'utilise une séquence identique pour une autre donnée, avec les variables initialisées de la même façon, et le nombre2 de celle ci est bien à 0 au départ.

Le plus fou, c'est que dans la version debug, nombre2 est bien à 0 dans les 2 cas, et dans la version release, 1 des deux nombre2 merde.

Enfin bref, c'est réglé, mais je suis dégoûté de mettre arraché les cheveux sur une incohérence informatique. Et pour anticiper la question de Mongaulois, ces variables sont initialisées dans le constructeur de mon thread, qui est crée au lancement de l'application, et le start() se fait bien plus tard (c'est une action de l'utilisateur). Donc aucun risque d'accès mémoire simultané.

Enfin bon, merci quand même,

G.

Le debug à tendance à initialiser des variable à zéro...

Juste au cas où, ça me semble louche,

Citation:

---

nbLecture = max(nombre1,nombre2)

---

c'est pas plutôt le min?

Citation:

---

nbLecture = max(nombre1,nombre2)

c'est pas plutôt le min?

---

Non c'est bien le max. En fait j'ai deux widgets qui affichent de façon différentes la même donnée, et si sur une widget l'utilisateur en demande 10 et sur l'autre 4, il faut bien que finalement j'en lise 10. Mais aucun risque car l'utilisateur ne peut pas demander plus de 20 valeurs.

G.