Bug Mémoire - ocx - Divers - Programmation
Marsh Posté le 17-04-2009 à 16:31:36
La quantité de mémoire disponible n'est pas le seul critère qui limite les applications. Il y en a d'autres. Par exemple, dans le cas des graphiques, il y a des limites au nombre de DC (display context), pen, brush, bitmap, font, etc. bref tous les objets du GDI. Dans les programmes bien faits, ces ressources du GDI sont libérées dès que possible, et il y a un test lors de la création d'un objet GDI qui échoue. Dans les programmes écrits pour êre compatibles avec Windows 16-bit (les programmes au format NE), le nombre des resources du GDI n'est pas très grand. Peut-être que l'OCX en question est dans ce cas. Pour les programmes au format Windows 32-bit (programme PE), le nombre des resources du GDI est très élevé, mais il se peut malgré tout que l'une des limitations soit atteinte dans certains cas.
Marsh Posté le 17-04-2009 à 17:59:35
Merci d'abord pour ta réponse rapide.
Mon fichier ocx est écrit en C++.
En fait je ne sais pas à quoi sert exactement l'ocx ?
Les ocx génèrent ils forcement des objets du GDI ?
Ya t'il une fonction qui puisse permettre de connaître le nombre de DC maximum qu'on puisse utiliser pour savoir ce qui fait que le bug arrive ?
Je voudrais pas forcement corriger le problème mais savoir exactement pourquoi il y a ce bug.
Merci
Marsh Posté le 17-04-2009 à 18:36:47
Quand je vois le message "Canvas does not allow drawing", et notamment le mot "drawing", je pense à une limitation concernant l'affichage, et non pas à un problème concernant l'OCX car l'OCX est juste un encapsulage d'un exécutable, et cela ne concerne pas l'affichage.
Il existe plusieurs moyens pour faire des affichages sous Windows. Le moyen le plus courant et le plus ancien est par l'utilisation du GDI. Comme l'OCX est une techique qui n'est pas très récente, j'ai supposé que votre OCX utilisait le GDI.
Pour avoir plus d'informations sur le GDI, voir l'article de Wikipedia, et notamment la version en anglais http://en.wikipedia.org/wiki/Graphics_Device_Interface , qui contient plus d'informations que la version en français. En voici un extrait :
Citation : The total available GDI [objects] varies from one version of Windows to the next. Windows 95, 98 and Millenium had a limit of 1,200 total handles, while Windows XP and Vista have a limit of 10,000 objects, and Windows 2000 has a limit of 16,384 objects. [8][9] |
Marsh Posté le 20-04-2009 à 10:52:40
Merci.
Après vérification, C'est exactement ça !!!
En suivant le nombre d'objets GDI dans le gestionnaire des tâches, je remarque que mon application bug lorsque le nombre atteint 10000 !!!
Je cherche donc maintenant si il y a un moyen d'augmenter la limite du nombre d'objets GDI car sur le site de Microsoft c'est marqué : "par default 10000"
Merci encore !
JM
Marsh Posté le 20-04-2009 à 10:59:09
10000 objets GDI ?
au lieu de traiter le symptôme (augmenter le nombre d'objets), faudrait voir à essayer de traiter la cause, et vérifier dans le source si tous les objets sont bien libérés, parce qu'il y a certainement un sérieux souci de fuite mémoire là
Marsh Posté le 20-04-2009 à 11:18:00
Comme je l'ai dit auparavant, il n'y a aucune fuite mémoire : cela a été testé avec plusieurs logiciels (tel purify) et de plus en suivant le processus la mémoire n'augmente pas.
Le nombre d'objets GDI augmente en fonction que les parametres sont insérés dans les pages ouvertes.
A chaque paramètre, 2 objets en + sont créé et au bout d'un moment ça sature.
Ma question reste donc : ya t'il un moyen d'augment la limite par défaut de 10000?
Marsh Posté le 20-04-2009 à 11:35:38
JM12345 a écrit : Comme je l'ai dit auparavant, il n'y a aucune fuite mémoire : cela a été testé avec plusieurs logiciels (tel purify) et de plus en suivant le processus la mémoire n'augmente pas. Le nombre d'objets GDI augmente en fonction que les parametres sont insérés dans les pages ouvertes. A chaque paramètre, 2 objets en + sont créé et au bout d'un moment ça sature. Ma question reste donc : ya t'il un moyen d'augment la limite par défaut de 10000? |
Oui, cette limite peut être modifiée dans le registre via la clé :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota
Mais je maintiens que c'est une solution bancale... 10000 objets GDI, c'est énorme pour une application. Quant à purify, no comment... Il m'a laissé passer des fuites de mémoire énormes, c'est le Norton Antivirus des anti-leaks...
Revérifie donc ton code toi même, et assure toi que chaque fonction Createxxx (avec xxx = "Pen", "Context", etc...) possède bien son DeleteObject() associé. Et si vraiment c'est OK, alors vois si tu peux repenser l'architecture de ton appli.
Marsh Posté le 17-04-2009 à 15:24:37
Bonjour,
J'ai un bug qui apparait lors de l'exécution d'un programme codé en delphi et c++.
La compilation se déroule bien, l'exécution au départ également.
Dans ce programme, il y a la possibilité d'ouvrir des pages contenant beaucoup de paramètres.
Lors de l'ouverture d'un trop grand nombre de pages, le programme bug et le message suivant apparaît :
"Canvas does not allow drawing" ainsi que parfois "System out of ressources"
Le processus ne prend pas trop de mémoire, même lors de l'ouverture des différentes pages (110 Mo).
Le code à aussi l'air bon : Rien n'apparaît lors de l'exécution "pas à pas" mise à part que sur la dernière page ouverte avant le bug, les paramètres apparaissent "grisés".
Aucune fuite mémoire n'a été détectée (testé avec plusieurs logiciels)
Je me demande donc bien pourquoi la mémoire est elle saturée ???
Une mémoire est-elle fixée lors de l'enregistrement du fichier ocx avec Regsvr32 ?
Comment windows gère les objets graphiques associés au contrôles OLE ?
Merci d'avance pour vos réponses.
JM