EOutOfResources - Ressources système insuffisantes

Version imprimable

03/07/2013, 17h30
benj63

EOutOfResources - Ressources système insuffisantes
Bonjour,

Dans mon application, je génère un BMP qui peut atteindre 1500x1500 pixels.
Code:

1 2 3 4 5 6 7 bmp = new TBitmap(); bmp->Width = 1500; bmp->Height = 1500; bmp->PixelFormat = pf24bit; //.... bmp->SaveToFile("monfichier.bmp"); delete bmp;
Il arrive que lors du SaveToFile, j'obtienne une exception "EOutOfResources - Ressources système insuffisantes". Pourtant, à ce moment là, mon exécutable n'occupe que 44 Mo en mémoire, et une image de 1500 x 1500 pixels n'a rien d'excessif...

A quoi cela est-ce du et comment le contourner ??

Merci pour votre aide !
03/07/2013, 17h38
benj63

A noter que cela ne se produit pas forcément lors de la génération du 1er bitmap, mais au bout d'un certain nombre. J'ai vérifié mes new/delete, il n'y a pas de souci de ce côté là, je les détruis bien au fûr et à mesure...

Salut, essai dans cet ordre avec ce code:

Code:

1
2
3
4
5
6
bmp = new TBitmap();
bmp->PixelFormat = pf24bit;
bmp->SetSize(1500, 1500);
//....
bmp->SaveToFile("monfichier.bmp");
delete bmp;

03/07/2013, 17h54
benj63

Merci pour le conseil, il faut donc mettre pf24bits avant de définir la taille ?
Et SetSize est essentiel ? Car je ne dispose pas de cette fonction dans ma classe TBitmap de BCB6 !

Citation:

Envoyé par benj63

Merci pour le conseil, il faut donc mettre pf24bits avant de définir la taille ?

Je crois que oui :weird:

Citation:

Envoyé par benj63

Et SetSize est essentiel ? Car je ne dispose pas de cette fonction dans ma classe TBitmap de BCB6 !

Si tu utilises les propriétés Width et Height alors SetSize va être appelé deux fois:
Code:

1 2 3 4 5 6 7 8 9 procedure TBitmap.SetHeight(Value: Integer); begin SetSize(FImage.FDIB.dsBm.bmWidth, Value); end; procedure TBitmap.SetWidth(Value: Integer); begin SetSize(Value, FImage.FDIB.dsbm.bmHeight); end;
Selon moi c'est mieux d’appeler la méthode qu'une seule fois.

04/07/2013, 08h57
benj63

J'ai suivi tes conseils mais malheureusement cela ne résout pas mon problème... L'exception apparaît encore + rapidement si je lance mon application avec Codeguard... y'aurait-il une fuite mémoire ailleurs ??

Pourtant en mémoire mon application ne nécessite que 48 Mo, BCB prend 100 Mo et il me reste + de 800 Mo de libre...

Je vais tenter d'extraire le bout de code générant un bmp dans un prog à part pour voir...
04/07/2013, 11h34
ShaiLeTroll

EOutOfResources n'est pas forcément lié à la mémoire mais plus souvent à nombres de handles utilisés !
C'est d'ailleurs utilisé de façon inappropriée dans Graphics.pas pour indiquer un retour 0 de GetDC ou de CreateDIBSection

Dans certains cas, cela gère tout de même le GetLastError pour mettre dans e.Message un peu plus de précision
Dans d'autres cas, on a juste "Ressources système insuffisantes" !

Cela n'oriente pas forcément sur le bon problème d'avoir un message d'erreur aussi peu précis !
04/07/2013, 14h08
benj63

Tu me conseilles de tenter de vérifier avec un GetLastError l'origine du problème ? et de contrôler le nombre de threads alloués à mon appli ?

Là ça devient grave, sur une machine sur lequel mon programme se lance beaucoup de fois, au bout de moins de 24 heures ça en arrive à empêcher Windows d'ouvrir Wordpad par exemple ("la création d'un document vide a échoué") !
04/07/2013, 14h31
ShaiLeTroll

Citation:

Envoyé par benj63

Tu me conseilles de tenter de vérifier avec un GetLastError l'origine du problème ? et de contrôler le nombre de threads alloués à mon appli ?

Non ! Ce n'est pas du tout ce que j'ai écrit !
Dans ton code, il sera trop tard pour invoquer GetLastError !

Je ne faisais qu'un constat de l'existant dans Graphics.pas et que le
gros défaut de EOutOfResources est une gestion imprécise de l'erreur dans la VCL !

Je n'ai pas évoqué les threads ... si tu as des threads qui manipule des TBitmap, il serait intéressant d'en parler d'ailleurs !

Citation:

Envoyé par benj63

Là ça devient grave, sur une machine sur lequel mon programme se lance beaucoup de fois, au bout de moins de 24 heures ça en arrive à empêcher Windows d'ouvrir Wordpad par exemple ("la création d'un document vide a échoué") !

Evidement, si l'OS n'a plus de Handle, il ne peut plus rien faire !
A Mon avis, tu as forcément des Handles qui traine :
- soit tu as une mauvaise libération dans ton code (systématises-tu try..finally ou les Smart_Ptr ?)
- soit un bug dans la VCL

Quelle version de BCB ? il y a eu des erreurs de ce genre dans la VCL, souvent corriger par un Patch, Update ou la version suivante !
04/07/2013, 14h48
benj63
Tout d'abord merci de te pencher sur mon problème.

J'utilise une vieille version : Borland C++ Builder 6

et ma création d'image BMP est lancée dans un thread de mon application... j'ai déjà remarqué à maintes reprises que les threads provoquaient des problèmes d'ailleurs, mais là je croyais que tout allait bien puisque je ne détectais aucune fuite mémoire, ni avec Codeguard, ni avec Memproof fourni avec BCB6...

Mon application ne crée qu'un seul thread, au démarrage de l'application.
Ce thread est créé en mode "suspendu".
J'ai une fonction Execute() avec un :
Code:

1 2 3 4 5 6 do { //.... plein plein d'opérations, dont la génération du bitmap ... // A la fin des opérations : Suspend(); } while(!TuerThread);
Le TuerThread est à false par défaut, je le mets à true dans le destructeur de mon thread.

Mon application lance toutes les 15 minutes ce thread, via un timer qui lance "monThread->Resume();" (le timer vérifie que le thread n'est pas déjà lancé)

Peut-être y'a-t'il un souci ? Mais ceci a toujours fonctionné jusqu'à présent...

Sinon pour répondre à tes questions :
- je n'utilise que des "try { } catch(...) { }" et pas de "finally"
- je n'utilise pas de smart_ptr car je ne sais pas comment les utiliser.
04/07/2013, 15h36
benj63

Histoire de voir s'il n'y a pas un souci au niveau des threads, j'ai utilisé le moniteur de ressources de Windows Server 2008 sur lequel mon application tourne, et je constate que le nombre de threads alloués à mon application reste fixe : "3"... donc je ne pense pas que cela vienne de là...
04/07/2013, 16h57
Crayon

Citation:

Envoyé par benj63

- je n'utilise pas de smart_ptr car je ne sais pas comment les utiliser.

Salut, voici un exemple sur le wiki d'Embarcadero qui utilise des std::auto_ptr: http://docwiki.embarcadero.com/CodeE..._%28C%2B%2B%29
04/07/2013, 21h09
henderson

Salut !

Il y a peut-être autre chose qui s'accumule en mémoire (non libéré ou mal libéré) !

Envisager d'utiliser GlobalAlloc et GlobalFree en lieu et place du reste (ça ne concerne pas le bitmap)!

A plus !
05/07/2013, 09h29
benj63

Citation:

Envoyé par Crayon

Salut, voici un exemple sur le wiki d'Embarcadero qui utilise des std::auto_ptr: http://docwiki.embarcadero.com/CodeE..._%28C%2B%2B%29

Merci pour l'exemple !
Donc à chaque fois que j'utilise un new TBitmap, il vaut mieux que j'utilise un auto_ptr ? A quoi cela sert-il exactement ? Et faut-il le privilégier pour les instances d'autres objets en particulier ?
05/07/2013, 09h34
benj63

Citation:

Envoyé par henderson

Salut !

Il y a peut-être autre chose qui s'accumule en mémoire (non libéré ou mal libéré) !

Envisager d'utiliser GlobalAlloc et GlobalFree en lieu et place du reste (ça ne concerne pas le bitmap)!

A plus !

Dans ma version de Borland (C++ Builder 6), j'ai une petite référence à GlobalAlloc, mais aucune référence à GlobalFree... Il faut utiliser cela à la place de tous les new/delete ?
A vrai dire cela m'inquiète un peu, j'ai toujours utilisé des new/delete ?
05/07/2013, 09h36
benj63

Sinon j'ai laissé tourner toute la nuit mon programme en regardant régulièrement le moniteur de ressources...

hier 16h50, démarrage de l'appli :
- Handles : 12612
- Threads : 684

ce matin 08h11 :
- Handles : 37800 8O
- Threads : 684

je ferme puis relance l'appli :
- Handles : 12960
- Threads : 684

C'est bien mon appli qui crée tout un tas de handles !
Comment contrôler cela, existe-t'il un outil de débogage pour suivre la création de handles et les fuites ?

Merci d'avance pour votre aide.

Hello,

Est-ce que ça s'améliore en lockant le canevas du bitmap ??

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
  Graphics::TBitmap* bmp;
 
  bmp = new Graphics::TBitmap();
  try
  {
    bmp->Canvas->Lock();
    bmp->Width = 1500;
    bmp->Height = 1500;
    bmp->PixelFormat = pf24bit;
    //....
    bmp->SaveToFile("monfichier.bmp");
  }
  __finally
  {
    bmp->Canvas->Unlock();
    delete bmp;
  }

05/07/2013, 11h19
ShaiLeTroll

Citation:

Envoyé par benj63

et ma création d'image BMP est lancée dans un thread de mon application... j'ai déjà remarqué à maintes reprises que les threads provoquaient des problèmes d'ailleurs,

Il faut faire attention, des sections critiques pour éviter du Read\Write simultané !

Citation:

Envoyé par benj63

mais là je croyais que tout allait bien puisque je ne détectais aucune fuite mémoire, ni avec Codeguard, ni avec Memproof fourni avec BCB6...

Codeguard sous XE3 ne pas détecté une fuite d'objet C++ type TObject, j'avais modifié mon code, sans le faire exprès un objet A et un objet B (des DelphiInterface géré par compteur de référence) était lié entre eux
A possède B, B a besoin de connaitre son A (un peu comme TControl.Parent)
C'est à partir du moment où j'ai ajouté dans A un std::map que Codeguard m'a détecté une fuite d'octet sur la map
J'ai peu corrigé B pour qu'il utilise en quelque sorte une référence faible sur A (un simple InterfaceA*) au lieu d'un DelphiInterface<InterfaceA>

Avant, j'ai donc plein de TInterfacedObject non libéré et non signalé par Codeguard !
DelphiInterface est l'équivalent du Smart PTR pour les classes d'implémentation d'interfaces à base de TInterfacedObject

Le new\delete est obligatoire pour tes TObject

Pour GlobalAlloc, c'est juste de la mémoire, pour un tableau ou struct, c'est tout à fait approprié, comme le mentionne henderson : ça ne concerne pas le bitmap

il faut faire juste attention à effectivement avoir autant de GlobalAlloc que de GlobalFree, un HGLOBAL est un handle, donc oui c'est une piste de fuite si tu utilises un GlobalAlloc quelque part

Citation:

Envoyé par benj63

Merci pour l'exemple !
Donc à chaque fois que j'utilise un new TBitmap, il vaut mieux que j'utilise un auto_ptr ? A quoi cela sert-il exactement ? Et faut-il le privilégier pour les instances d'autres objets en particulier ?

std::auto_ptr c'est juste le principe du RAII standardisé
Voir aussi Quel est l'équivalent C++ du bloc finally des autres langages ?

Si tu programme en OO style Delphi, tu dois encaspuler tout cela dans tes propres objets, veiller à ce que constructeur\destructeur soit robuste et libère tout ce qui est alloué
En cas d'exception, le finally garanti la libération éventuelle d'un objet comme TBitmap, TStringList, TForm, TThread en fait tout ce qui est TObject doit être protégé soit par un try finally soit encaspulé par une autre classe, au final, tu auras surement un try finally qui assura la libération

Si tu programme en OO style C++, le RAII se base sur la portée de bloc des variables, lors tu sors d'un bloc {}, cela invoque automatiquement les desctructeurs des struct\class instancié en allocation statique
Qu'est-ce qu'un pointeur intelligent ?

Comment utiliser les pointeurs intelligents de Boost ?

Ne pas confondre auto_ptr et smart ptr, cela semble être similaire mais c'est très subtile :
Pourquoi faut-il se méfier de std::auto_ptr ?

allocation statique c'est juste mastruct mavariable;
allocation dynamique c'est mastruct *mavariable = new mastruct();
allocation dynamique RAII c'est std::auto_ptr<mastruct> mavariable = new mastruct();

En allocation dynamique, il faut faire le delete, le Smart\Auto Ptr est une struct en allocation statique dont les opérateurs ont été redéfini pour donner accès à l'instance en allocation dynamique dont on lui a confié la "garde"
Lors de la sortie du bloc, cela invoque le destructeur du Smart\Auto Ptr qui ne fait qu'une seule chose : invoquer le destructeur de l'instance en allocation dynamique

Personnellement, je suis un Delphiste, donc en C++ je profite du __finally, je code ainsi exactement de la même façon qu'en Delphi, ce qui est bien plus prudent lorsque l'on utilise la VCL\RTL !