Which objects must be released explicitly

[Antonio Linares]

Enrico and others,

This concept is quite simple and common for all operating systems:

An application can not put in risk the stability of the operating system. Specially for those operating systems designed to run multiple applications simultaneously.

This concept is fundamental for the stability and security of an operating system. In other words: if this simple concept fails, then the entire operating system could crash due to an application activity. So the operating system protects itself against these potential problems.

On next msgs we are going to check this concept with some simple examples.

[Antonio Linares]

1. Lets try to block the system:

On this example I try to block Windows, calling a recursive C function. Please run this test and see how Windows detects the problem and blocks the application:

Code: Select all  Expand view  RUN

function Main()

  CrashTheSystem()

return nil

#pragma BEGINDUMP

#include <hbapi.h>

void CrashIt( void )
{
   CrashIt();
}

HB_FUNC( CRASHTHESYSTEM )
{
   CrashIt();
}

#pragma ENDDUMP   


[Antonio Linares]

2. In this example we are going to create a crazy amount of brushes without releasing them. Please open the task manager and check the physical memory used: You will notice that it remains the same after the application execution:

Code: Select all  Expand view  RUN

function Main()

   CreateLotsOfBrushes()
   
return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( CREATELOTSOFBRUSHES )
{
   LONG l;
   LOGBRUSH lb;
   
   lb.lbStyle = BS_SOLID;
   lb.lbColor = RGB( 255, 255, 255 );
   lb.lbHatch = HS_CROSS;
   
   for( l = 0; l < 10000000; l++ )
      CreateBrushIndirect( &lb );
}

#pragma ENDDUMP       


[Antonio Linares]

3. In this example we are going to try a direct attack to the operating system: We request a huge global memory, so Windows will not know if such memory has to be released, so the entire system can get in danger. But again, Windows properly protects itself. Please check physical memory from the task manager:

Code: Select all  Expand view  RUN

function Main()

   SystemAttack()
   
return nil

#pragma BEGINDUMP

#include <hbapi.h>
#include <windows.h>

HB_FUNC( SYSTEMATTACK )
{
   LONG l;
   
   for( l = 0; l < 10000000; l++ )
      GlobalAlloc( GMEM_FIXED, 10000000 );
}

#pragma ENDDUMP


[Enrico Maria Giordano]

Great! Thank you for the samples.

EMG

[Enrico Maria Giordano]

On which Windows versions did you try the samples?

EMG

[Antonio Linares]

Enrico,

Vista Ultimate 32 bits

[Enrico Maria Giordano]

I wonder if it's the same on older Windows versions...

EMG

[Antonio Linares]

Enrico,

Probably not.

[Enrico Maria Giordano]

Then better properly release resources.

EMG

[Antonio Linares]

Enrico,

Yes, of course. Nobody is saying the opposite.

FiveWin properly releases the ones used by the windows, dialogs and controls. If the programmer creates some more, besides those, then he is responsable for releasing them.

Though FiveWin will automatically release them at the exit of the application, in the case that the programmer didn't do it properly, and Windows itself will clean the whole application workspace finally.

[MOISES]

Hi,

New Harbour 1.00 RC 2 creates a file, hb_out.txt, indicating which objets are not release from memory.

[Antonio Linares]

Moises,

We are talking about Windows GDI objects here.

Anyhow, thanks for your info. Though I guess its Harbour responsability to release all created objects from Classes, as a result of its garbage collector activity.