crash quasi systématique de mon appli dans module cbn qui thread beaucoup !

Bonjour,

en refaisant un peu le tour de tous les modules de mon appli, je m'aperçois que mon module CBN occasionne un crash quasi systématique, avec à la clé les erreurs suivantes :

http://img11.hostingpics.net/pics/911680err1.jpg

http://img11.hostingpics.net/pics/214238err2.jpg

Ca ne le fait pas tout le temps, ça dépend des données qui vont être mobilisées par le cbn, et là je me trouve dans une configuration telle que le module cbn crash 1 fois sur 2, un coup il aboutit et me sort ma cinquantaine de propositions attendues, le coup d'après il plante de façon aléatoire sans aller au bout (parfois à 50%, parfois à 80, parfois tout à la fin)...

De quoi ça peut venir d'après vous ? Pb de libération mémoire ? J'ai quand même du mal à me dire que j'ai un problème de programmation sachant qu'une fois sur deux ça va au bout.

Ceci étant, en surveillant le process WDTst.exe je m'aperçois que les fois où ça plante, le processus génère en quelques secondes une augmentation de consommation mémoire très importante, je suis à 15-16 Mo en fonctionnement normal, et juste avant le plantage ça grimpe à 58Mo en l'espace de 2 secondes, et ça crash.

Toute aide est la bienvenue pour isoler le problème.

Merci à vous

je voudrais rajouter quelques précisions :

quand le crash arrive, cela ne m'empêche pas de continuer à utiliser mon appli, il faut juste que je ne valide pas le premier popup d'erreur, je repasse mon appli au 1er plan et je continue de bosser.

Ma fenêtre cbn étant toujours ouverte, je reclique sur le bouton qui commande l'exécution du cbn, et là il me sort une connerie du genre 5 ou 6 propositions. Bon je présume qu'il est dans un état mémoire un peu perturbé.

Qu'à cela ne tienne, je ferme cette fenêtre, mais mon appli est toujours ouverte. Je rouvre une nouvelle fenêtre CBN, et j'exécute un nouveau calcul. Cette fois il me sort les 54 propositions attendues à la vitesse de l'éclair, il met 10 secondes à peine pour me les calculer, alors qu'avant plantage, un calcul qui aboutit prends environ 30 secondes. Vraiment étrange. Et encore plus étrange est qu'à partir de ce moment là (après crash et en ignorant le message d'erreur sans le valider, sinon fermeture de l'appli) je ne rencontre plus aucun plantage, le cbn aboutit systématiquement, il est parfaitement juste, et surtout extrêmement rapide !!!!

Bonsoir,

Une erreur fatale GPF c'est souvent des objets utilisés en simultanés d’où le crash...

Ton thread utilise t'il des variables utilisées dans d'autres threads en même temps ?

Bonjour,

en fait le titre de mon sujet est faux, je lance le calcul CBN dans un thread car il est lourd et parfois pourrait figé l'appli, mais les références qui pourraient potentiellement nécessiter des propositions du CBN sont connues à l'avance dans un tableau, et je lance le traitement CBN successivement sur chaque référence du tableau. Donc pas de ressources ou d'objets partagés entre plusieurs thread, seulement une table dans laquelle j'ajoute au fur et à mesure les propositions suggérées par le cbn...

Mouais...

As tu essayé de faire le calcul dans le thread principale et faisans des pauses en redonnant la main au programme avec des Multitache(-1) ? Cela permettrais de ne pas figer l'appli et de voir si c'est le thread secondaire qui provoque le crash.

en fait je n'ai jamais compris le fonctionnement de cette instruction, c'est pourtant pas faute d'avoir lu pas mal de sujets dessus. Je comprends pas pourquoi parfois on met une valeur négative (-1) parfois très très négative (-100) ou à l'inverse (100) et le petit jeu de à toi / à moi que cela génère entre les threads.

Je vais explorer cette piste un peu plus sérieusement, mais si tu as une explication plus claire que la doc pcsoft, alors je prends !

Je n'ai jamais vu de Multitache(-100) par contre, c'est assez simple :

Multitache(0) > rend la main à Windows
Multitache(-1) > rend la main à ton code + Windows

Citation:

---

Envoyé par WDKyle

Je n'ai jamais vu de Multitache(-100) par contre, c'est assez simple :

Multitache(0) > rend la main à Windows
Multitache(-1) > rend la main à ton code + Windows

---

D'accord mais si je fais un Multitache(0), qu'est-ce qui va redonner la main à mon appli ?

admettons que j'ai une suite d'instructions :

Code:

---

1 2 3 4 5 6 7

instruction 1 instruction 2 ... Multitâche(0) ... instruction n-1 instruction n

---

Sachant que j'ai redonné la main à Windows, quand les instruction n-1 à n vont elles reprendre ?

Et Multitâche(-1) je comprends toujours pas. Qu'est-ce qui rend la main au code + Windows ? Le Multitache(-1) est déjà dans mon code non ?

En fait, cela ne fais pas vraiment de "pause" dans ton code, c'est juste que cela permet à ton application de rester "active" pour Windows et donc que cela n'affiche pas "Ne réponds pas..." si tu clique sur une fenêtre de ton appli pendant un traitement long.

Si tu met Multitache(100) tu va sentir une vrai pause d'une seconde mais Multitache(0) ou Multitache(-1) c'est transparent.

Formidable !! Je lance mon cbn dans le thread principal et je fais des multitâche(-1) à chaque fois qu'une proposition doit être ajoutée dans la liste.

Maintenant plus de plantage, et surtout le calcul est 5 à 10 fois plus rapide.

J'ai du mal à comprendre pourquoi un appel dans un thread est plus lent que dans le thread courant. J'avais remarqué avant, que lorsque je lance le thread de cbn, le processus ne se voyait alloué que 5% maxi de cpu. Alors que maintenant, en appelant cbn depuis le thread principal, le cpu grimpe parfois à 20-25%, du coup le calcul se fait bien plus rapidement.

Ca m'amène à cette question : finalement pourquoi utiliser le mécanisme de thread pour lancer des traitements en parallèle de l'utilisation principal de l'appli, si rien qu'avec l'instruction Multitache on peut avoir le même confort d'utilisation, et surtout des traitements plus rapides ?

Encore merci à toi WDKyle

C'est quand même pas l'idéale pour d'autres traitements qui doivent se faire en simultané tout au long de l'utilisation du logiciel, sans l'action d'utilisateur.

Pour la rapidité peut-être que cela est dû à la fonction Threadmode() ? Je n'en sais pas plus...

Content que ça fonctionne pour toi ! :)

Bonjour,

j'aimerais apporter un complément à ce qui a été dit plus haut. Dans le cas d'une utilisation d'un thread secondaire il ne faut en aucun cas utiliser la fonction Multitâche. Nous avons été confronté a un problème similaire (c'était sur mobile, mais après discussion avec l'assistance directe ce conseil peut être généralisé à Windev) et l'utilisation de la fonction multitâche amenait des comportements inattendus.

Il faut utiliser à la place la fonction ThreadPause avec une valeur strictement positive (le thread secondaire ne bloquant de toute façon par le thread principale, il n'y a pas de raison de vouloir rendre la main au système pour rafraîchir une IHM par exemple).

Il faut également éviter l'utilisation de variables globales utilisées par différents threads (ça provoque le genre de message au début de ce fil de discussion). Donc comment communiquer entre les différents threads ? Une solution qui fonctionne extrêmement bien est de stocker la valeur d'une variable globale dans un fichier HFSQL. Cela permet un accès simultané (géré par HFSQL) sans problème. Certes c'est plus lent, mais entre une application plus lente fonctionnelle et une plus rapide qui plante mon choix est vite fait.

Bonjour,

Je n'est jamais parlé d'utiliser Multitache() dans un thread secondaire. Bien au contraire, j'ai dis d'utiliser cette fonction pour rendre la main à Windows pendant un traitement long effectué dans le thread principale.

Pour ce qui est de l'utilisation de variables globales dans plusieurs threads simultanement, pas besoin de fichier HFSQL, il suffit simplement de mettre en place des sémaphores.

Oui effectivement j'ai lu trop rapidement. Cependant ma remarque reste valable et j'espère évitera quelques problèmes à celui qui utilise les threads secondaires.

Pour les sémaphores c'est effectivement possible mais nous n'avons pas retenu cette solution car il y a un gros risque de blocage (deadlock). C'est toujours la même chose : sur un petit projet test ou l'on fait attention il n'y aura pas de souci, une fois que l'on travaille sur un plus gros projet et que l'on est plus focalisé sur la partie opérationnelle on peut oublier cette partie relativement délicate d'inter blocage d'où notre choix pour le fichier HFSQL.