Thread et mutex, plantage.

[Lolilolight]

Salut,
je possède 2 threads : un qui mets à jour l'affichage, un autre qui affiche.
J'utilise également un mutex pour que mon autre thread ne modifie pas la scène pendant que le thread principal la dessine.

Cependant sous seven, parfois ça plante en plein milieu de l'application et ça m'affiche celà dans le débgueur :

Code: [Sélectionner]

#0 771104E5 ntdll!TpWaitForAlpcCompletion() (C:\Windows\system32\ntdll.dll:??)
#1 0028BD00 ?? () (??:??)
#2 770F5732 ntdll!RtlLargeIntegerDivide() (C:\Windows\system32\ntdll.dll:??)
#3 079F1E48 ?? () (??:??)
#4 770D29FA ntdll!RtlCopyExtendedContext() (C:\Windows\system32\ntdll.dll:??)
#5 ?? ?? () (??:??)

Comment pourrai-je avoir le nom des fonctions ou ça plante ?
Je sais que c'est un problème de mémoire, mais, je n'arrive pas à retrouver dans quelle fonction que c'est. 

[Laurent]

Alors là... Si la pile d'appels n'est pas plus précise, ça va être difficile. Essaye de retirer des choses de ton code, ou bien de le baliser avec des "std::cout << __LINE__", etc.

[Lolilolight]

Je me retrouve souvent avec quelques crash comme ça par ci par là (ça ne plante pas tout le temps mais assez souvent, surtout quand j'utilise les threads sinon ça ne plante pas mais c'est trop lent mon application en mono-thread, vu que c'est une grosse appli que je suis entrain de faire, style mmorpg.)
Il faudrait que j'essaye sur d'autres OS pour voir si j'ai les même crash, sur linux il me donnera peut être plus de détails. (Parfois ça arrive même que ça ne compile même pas sous linux à cause d'une erreur hors que sous windows ça compile.)

Bref..., je vais devoir repassez sous linux de toute façon, mon éditeur de map ne veut plus du tout se lancer son windows hors que sous linux il se lance sans problème, et c'est pourtant le même code.
Ce qui est un peu, inquiétant. ^^
Bref je vais repasser sous nux maintenant que ça fonctionne +/- sous windows.

[Lolilolight]

Ha bah sur linux il m'affiche plus de détails, c'était bêtement un conflit de partage de variable entre plusieurs thread, par contre, la vue se déplace vachement plus lentement sous linux que sur windows et pourtant j'ai mis la même vitesse des 2 côtés pour mon personnage. 
Bon bah je vais pouvoir entamer le codage du gameplay! 

[Eroy]

Hum...
Le fait de locker le modifier pendant le draw implique que ton thread de positionnement ne fera rien avant la fin du draw... Et donc tu te retrouve avec une synchro entre les deux threads. A ce compte tu y perdras même en perfs quand tu feras de gros calcules par rapport à du mono.

Threader la sfml avec un résultat stable et utilisable en release ça a une différence gains/temps qui ferait vomir un chef de projet alors ça doit être justifié par une architecture spécifique derrière...

Si tu veux le faire car ton application est trop lente en mono alors c'est encore plus une mauvaise idée car ce n'est surtout pas une solution pour régler un code non optimisé ou algo mal pensé, ça ne fera que le camoufler quelques temps. Je pense que tu es en train de te tirer une balle dans le pied.

[Lolilolight]

En effet j'ai eu se soucis là, je suis revenu en mono-thread et, ça va, ça passe, donc je vais laisser comme ça.
Y'a juste un plantage à la fermeture de l'appli : pure virtual fonction call.
Mais le débugueur ne me donne pas trop d'infos à ce niveau là donc..., faudra que j'essaye avec la SFML et Qt en mode débug pour voir (là le débugueur me donne paroifs plus d'info.)
Mais je chercherai après car ça ne me gêne pas pour faire la suite.

PS : oui ce sont bien les renderTextures. ^^