hello,
 
ca fait une journée entière que je lutte avec ce Visual C++, et je ne comprends pas.
 
Ce que je fais:
J'ai un petit bout de code tout bête qui récupère l'entrée micro de la carte son. Rien d'exeptionnel. Pour tester, je lance ca avec une application console.
 
Mon pb:
- si je lance le .exe (compilé avec les optons de debug) dans une fenetre dos, ca plante (la fonction waveInPrepareHeader me retourne un code d'erreur).
 
- si je lance le même programme, mais cette fois depuis l'environement Visual C++, avec le debugger, alors cela ne plante pas. Par contre, je n'arrive plus a arreter le programme. C'est a dire que même si j'arrete le debugger, il reste une tache de fond (qui porte le nom de mon programme de test) que je ne peut même pas killer avec le gestionnaire des tâches. Seule solution: redemarrer le PC (fermer la session et en ouvrir une autre n'a aucun effet, et même l'administrateur ne peut pas killer ce processus).
 
Donc si qq1 a des idées.
Pour infos: NT4, VC++, bi-pro ( et je pense avoir mis des protections pour le multithread partout la ou il faut...)

bon, vous pouvez lacher l'affaire:
 
1. parce que ca y est, ca fonctionne...
2. parce que personne n'a l'air interressé par ma question
 
par contre, je ne comprends toujours pas pourquoi ca fonctionnait qaund j'utilisais le debugger mais pas quand je lançais directement l'executable.
Si qq1 a une explication...

SoWhatIn22 a écrit a écrit : bon, vous pouvez lacher l'affaire:   1. parce que ca y est, ca fonctionne... 2. parce que personne n'a l'air interressé par ma question   par contre, je ne comprends toujours pas pourquoi ca fonctionnait qaund j'utilisais le debugger mais pas quand je lançais directement l'executable. Si qq1 a une explication...

Tu fais du multi-thread sur un bi-pro ?
Quels sont les protections que tu a pris ?

ben vi, je fais du multithread sur un bi-pro. Sans multithread, le bi-pro perd quand même pas mal de son interêt, tout du moins en ce qui me concerne.
 
Les protections, ben ce sont les grands classiques du genre: mutex, semaphores et sections critiques.

1- peux-tu reproduire le Pb en mono proc
2- as-tu utilise des raisonnements du genre : "je viens de lacher le mutex donc je peux encore..." ou "la proba est si faible que..."
 
En fait le multi-threading en mono ou en multi proc est tres different, des pb qui n'apparaissent pas avec n proc apparaissent avec n+1 !
 
3- As tu des mutexes en cascade (ou zones critiques)?
c'est le cas le plus frequent de dead lock...
 
Beaucoup des Pb de multi-threading sont probabilistes et les differences de comportement en fonction de la facon dont tu lances ton appli me laisse supposer que tu as deux Pb :
A - un acces a un pointeur non valide (peut etre libere par une autre thread) d'ou plantage (vive Unix et les core dump)
B- un Pb de dead-lock entre tes threads d'ou le blocage...
Il y a fort a parier que aucuns de ces problemes ne se manifesterait en mono-proc parce que les acces concurents sont bcp moins problematique.
 
Tu peut utiliser le bi-pro en multitache conventionnel il y a beaucoup moins de pb.
 
As-tu verifie que tu uilise les bonnes lib (c'est tres courant)
 
3 - les Pb etant d'ordre statistique (collision) il peuvent apparaitre et disparaitre aleatoirement
 
Le seul moyen de resoudre les acces concurent c'est de verifier tout les Mutex (bon courage) et les donnees et codes qu'ils protegent...
 
Le seul moyen de resoudre le dead lock c'est de chercher les empilages de Mutexes...

nan, pas de pb du côté des mutex ou autres...
je crois que j'ai trouvé le soucis.
 
Je suis obligé d'utiliser l'API et les types de Microsoft pour faire la prog de la carte son sans que cela me prenne 2 mois.
Le soucis, c'est que leur doc sur le sujet est assez légère.
 
Alors voila les 2 soucis que j'avais, ainsi que les 2 solutions:
 
1. Le programme fonctionne avec le debugger de Visual C++ mais pas quand je lance l'exe.
 
Visiblement, leur debugger a la con initialise un certain nombre de variables si cela n'a pas été fait à l'init. Or il y avait un champs dans le recoin d'une structure definie par microsoft que je n'avais pas initialisé, because je pensais qu'il ne fallait pas.
Comme le debugger le faisait à ma place, je n'avais pas le soucis en debug, et ca plantait lamentablement en lancant l'exe.
 
 
2. Une fois le pg apparement fini, il reste un process zombie que je n'arrive pas à killer.
 
Dans ses fonctions systeme, winNT verrouille des zones de mémoire, et ne les dévérouille que lorsqu'on le demande explicitement. Donc si le programme plante avant que cette liberation ait été demandée (genre on arrete le debugger brutalement, on on a une exception...), ces zones de mémoires ne sont pas libérés.
C'est tres con parce que si le pg a planté, on n'a justement plus la main dessus et donc on ne peut plus unlocker ces zones.
C'est de plus assez etonnant que cette liberation ne soit pas automatique en fin de processus, comme cela peut l'être pour des zones allouées dynamiquement avec un new ou un malloc et que l'on oublierais malencontreusement de désallouer.
 
 
Peut être (et même sans doute) y a-t-il une solution pour éviter cela, mais dans l'immédiat je ne vois pas...
 
 
Seule solution a mon pb: faire un programme qui ne plante pas!

Desolee de te faire perdre ton temps...
comme mon MT je le fais plutot sous Unix j'ai pas de PB MS...

nan nan nan, pas de perte de temps, et t'as pas à être désolé... je te remercie de tes idées. De toute façon, qd ca marche pas, toutes les idées sont bonnes à prendre
 
Quant à Unix, ben des que mon truc fonctionne sous winNT, faudra que je le porte sous Unix et Linux. Bon, faut vite que ca fonctionne sous win. je prefere quand même moi aussi les 2 autres ...

SoWhatIn22 a écrit a écrit : nan nan nan, pas de perte de temps, et t'as pas à être désolé... je te remercie de tes idées. De toute façon, qd ca marche pas, toutes les idées sont bonnes à prendre   Quant à Unix, ben des que mon truc fonctionne sous winNT, faudra que je le porte sous Unix et Linux. Bon, faut vite que ca fonctionne sous win. je prefere quand même moi aussi les 2 autres ...

 
Bon courage pour porter le Multi-Thread (le reste aussi sans doute).
Regarde quand meme www.wxWindows.org (y vont me virer du forum parce que j'en parle trop) ca marche sous Win-Motif-GTK et il y a un module wxThread... Comme ca ton portage sera plus facile.
(je regarde, j'ai pas encore eu le temps de mettre en pratique)