Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 24

Thread: Memory leaks

  1. #11

    Memory leaks

    You must free the image yourself, override the destroy procedure and add in the freeing in there.

  2. #12

    Memory leaks

    Quote Originally Posted by User137
    I would find it hard to imagine WinXP could not handle and free application's own memory spaces.
    I think the memory is recovered when the app closes on most modern OS's. But if you don't worry about memory management while you app is running your app will probably run out of memory while running, especially if you are creating lots of objects but not freeing them.
    <A HREF="http://www.myhpf.co.uk/banner.asp?friend=139328">
    <br /><IMG SRC="http://www.myhpf.co.uk/banners/60x468.gif" BORDER="0">
    <br /></A>

  3. #13

    Memory leaks

    Quote Originally Posted by Robert Kosek
    You must free the image yourself, override the destroy procedure and add in the freeing in there.
    That would be too obvious But isn't TForm freeing its child objects too, so why not other objects? Maybe its destructor just has a loop that frees them all, or maybe the thing i read some point was all about application closing. I'm just playing around with the idea finding the limitations...not that i would leave the .Free's uncalled Delphi is quite high level language already with much automation.

  4. #14

    Memory leaks

    If you don't free it, it's not freed. So if you free a class with sub-objects that aren't freed in your Destroy() destructor, you'll have a substantial block of allocated memory remain.

    ... Are you trying to follow in Adobe's footsteps?

  5. #15
    Legendary Member cairnswm's Avatar
    Join Date
    Nov 2002
    Location
    Randburg, South Africa
    Posts
    1,537

    Memory leaks

    Basicaly the rule in Delphi is - if you create something you must destroy it.

    While TForm distroys each of its child components you must remember that each Child Object is included in the Components list of the form. Therefore the Form knows about the components and can then destroy them each as it closes.

    When you create a stringlist inside another class the class itself does not actually know about the string list (it only contains it) and therefore does not know that it needs to destroy it.

    When I create a 'Map' object in my games I will typically register all child objects into the Map

    [pascal]TBaseItem = Class;

    TMap = Class
    Items : TList;
    Constructor Create;
    Destructor Destroy;
    Procedure AddItem(NewItem : TBaseItem);
    End;

    TBaseItem = Class
    Map : TMap;
    End;
    [/pascal]

    So Whenever a new item is created the Map.AddItem is called which adds it to the Items list.

    When the Map is freed

    [pascal]Destructor TMap.Destroy;
    Var I : Integer;
    Begin
    For Items.Count-1 downto 0 do
    Begin
    TBaseItem(Items[I]).Free;
    End;
    End;
    [/pascal]

    Which ensures that the Map frees all the items in the same way that a form frees all the components that are on it.


    If you create an instance of a class, you are responsible for freeing it.
    William Cairns
    My Games: http://www.cairnsgames.co.za (Currently very inactive)
    MyOnline Games: http://TheGameDeveloper.co.za (Currently very inactive)

  6. #16

    Memory leaks

    (This thread is under Delphi, but I couldn't resist to mention here how it's for FPC.)

    FPC already includes memory leaking unit, it's called HeapTrc. You can explicitly add it to your uses clause (just like some other mem leaker detectors for Delphi, since they should work with FPC as long as they do not depend on any Delphi internals). You can also just compile your program with -gh command-line option, this implicitly adds HeapTrc to your uses clause (this is handy, because this way you don't have to edit source code to turn mem leaking detecting on; you only change the FPC command-line, or "Compiler Options" in Lazarus).

    There is also a related option -gc that activates pointer checking. And another related option is -gl, this inserts line information into your executable. Together all these options will notify you about any access to wrong place in the memory (without them, it's never guaranteed that you will get segfault), and any memory leak. And you will get backtrace telling you exactly where you tried to access invalid pointer or where you allocated memory that was left unallocated at program exit.

    So if you're using FPC, it's highly adviced to compile all debug code with -gh -gl options. -gc is also great, although in some cases it can slow down the code too much.

    That would be too obvious Wink But isn't TForm freeing its child objects too, so why not other objects?
    cairnswm already explained it, I'll just say it once again using different words:

    Every descendant of TComponent (like TForm) frees all the objects it "owns". One component is an owner of another when it's passed as the AOwner parameter to the constructor. This means that when you create MyObject like

    [pascal]
    MyObject := TMyObject.Create(MyOwnerObject);
    [/pascal]

    then MyObject will be automatically freed when MyOwnerObject will be freed. All you have to do for this is to make MyObject and MyOwnerObject classes descend from TComponent.

    You can also use TObjectList class, it will automatically free it's items when OwnsObjects is true.

  7. #17

    re-

    Have anyone tried this memcheck unit?,

    I did a litle test in regular delphi project (I mean using Dpr, forms and unit1.pas), i added a button to the form and in the onclick button event i added:



    Code:
    procedure TForm1.Button1Click&#40;Sender&#58; TObject&#41;;
    var
    p&#58;pointer;
    begin
        getmem&#40;p,64*1024&#41;;
    end;
    I have placed memchk procedure call in the form create event, then when the program is running, for each click in the button a 64kb memomy block is allocated; when i close the program the memcheck indeed informs me accurately the amount bytes allocated (and never released meanwhile the program was running); it also tells me that i used Getmem for allocate the memory however the unit is unable to show me where in my source code i am allocating that memory.

    I have enabled the debugger and turned On the stack frames and all debug options in the project options (as the unit's documentation tells), then i tried again but still there is not easy way to found that the problem happen in my onclick code in unit1.pas, the debugger opens system.pas and stops in a line inside, seem procedure getmem() calls lot sub procedures/functions, in fact the checkmem reports 21 stacks calls, (mean since i click the button then about 21 procedures/functions are called in the procces).

    Yes, knowing your program is leaking memory is very usefull, but also knowing where it happen in your code should be a MUST, specially in biggers projects like a video game;

    how you guys usually found where you have the problem in your code?

    thank you,

    tp.

  8. #18

    Memory leaks

    Haven't found any memoryleaks in my code yet but they are probably there...
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  9. #19

    Memory leaks

    Hey, I've been using Memchk for some time now.

    I actually used it on my Chrome plugin for FLStudio..

    To get it to give you a location in your code,
    like the documentation says:
    Go to Project -> Options -> Compiler Tab:

    • - Disable Optimisation
      - Enable Stack-frames
      - But here is the important one:
      You must go to the Linker tab and enable 'Include TD32 Debug Info'


    Project -> Build (This is important!)

    This will make your exe about 6mb big, so only use it for testing obviously!
    My site: DelphiTuts.com (coming soon)...

    Download Font Studio 4.21 here.

  10. #20

    Memory leaks

    Project -> Build (This is important!)
    That's what i was mising!, i was just using f9 for compile and run the app.
    After doing "projects,build" now the memchecks is able to tell me the unit and the line number where i allocated the memory block, :-)

    thank you, this tool is really usefull and easy to use.

    tp.

Page 2 of 3 FirstFirst 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •