|
Sujet : [VC++] pbs en debug ????? |
| BENB |
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) |
| SoWhatIn22 |
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! |
