Thread: Memory deallocated.

  1. #1
    Registered User
    Join Date
    May 2008
    Posts
    21

    Memory deallocated.

    Is there an easy way to determine how much memory an object is allocated? If I overload delete on an object, from which other objects are inherited - can keep track of how much memory is deallocated (and conversely how much is allocated) ??? So perhaps I could keep a static count of how much memory is outstanding (still allocated) at the end of my program?

  2. #2
    Registered User
    Join Date
    Aug 2004
    Location
    San Diego, CA
    Posts
    313
    ...wouldn't it just be sizeof()?

  3. #3
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Lithorien View Post
    ...wouldn't it just be sizeof()?
    Not for something allocated with new[]

  4. #4
    Registered User
    Join Date
    Aug 2004
    Location
    San Diego, CA
    Posts
    313
    Quote Originally Posted by brewbuck View Post
    Not for something allocated with new[]
    Ah, sorry.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    You can use platform-specific functions like _msize() to get the size of an allocated block.

    But instead of writing your own leak detector, you could just use a leak detector library. There are various.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #6
    Registered User
    Join Date
    May 2008
    Posts
    21
    I'm actually not really worried about memory leaks, I'm quite cautious when writing my code - however I like the idea of tracking a leak detector - for curiosity's sake if anything.

    If it is possible to achieve this - I'd certainly like to do it, just because I'm a particularly curious person and managing everything may be overkill but it's a nice challenge.

    Also monitoring the amount of memory usage my application is averaging under full load would be particularly beneficial for it's purpose.

  7. #7
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    You can override the new and new [] operators and the delete and delete [] operators to keep track of how much memory is allocated & deleted and store that info in a global variable. I believe that's how most memory leak detectors do it.

  8. #8
    Registered User
    Join Date
    May 2008
    Posts
    21
    Well yes, that's a given. But how can I determine how much is in fact deallocated?

  9. #9
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by scarecrow View Post
    Well yes, that's a given. But how can I determine how much is in fact deallocated?
    How do you mean?

    In your (presumably common) actual memory allocation and deallocation routines, you store the size of the allocation. Whether it is plain new or new [], when you deallocation with delete or delete [], you should get the same pointer back to the corresponding delete function. You should allocate a bit extra memory [to make sure that you don't get alignment problems, make sure that this extra memory is a multiple of 16 bytes], and keep a linked list of all your allocations. If you want to check for "bad delete", run through the list and check that the original pointer is in there [and perhaps mark whether it is new or new[] that created the allocation, and that it matches with the delete call made].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  10. #10
    Registered User
    Join Date
    May 2008
    Posts
    21
    And suddenly I realise how simple and stupid my problem actually was. Thanks for some perspective.

    So would I always allocate exactly 16 bytes? Or should I weight this to increase more (in multiples as you said) for larger allocations?

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by scarecrow View Post
    And suddenly I realise how simple and stupid my problem actually was. Thanks for some perspective.

    So would I always allocate exactly 16 bytes? Or should I weight this to increase more (in multiples as you said) for larger allocations?
    What I meant was that if you put a "block at the start of the allocation", it should be 16, 32, 48, 64, etc bytes. That way you will be guaranteed that you are not breaking any C library alignment rules.

    And here's an example:
    Code:
    struct allocation
    {
        int id;
        struct allocation *next;
        size_t size;
        int line;
        char *file;
        union {
           int fill[3];   // we have 5 integers above, so add another 3 to make 8 => 32 bytes. 
           double filld;   // This makes sure your allocation is in itself aligned to 8 bytes. 
        };
    }
    
    ..
    void *mymalloc(size_t size, char *file, int line)
    {
        struct allocation *a;
        size_t fullsize = sizeof(*a) + size;
        a = malloc(fullsize);
        a->id = 12345678;
        a->size = size;
        a->file = file;
        a->line = line;
        ... insert a into linked list or some such. 
        return (void *)&a[1];
    }
    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #12
    Registered User
    Join Date
    May 2008
    Posts
    21
    Interesting. Curious about your line and file parameters there - assuming you were to use __FILE__ and __LINE__, would this mean every time you wanted to allocate some memory you'd have to type that in as well?

  13. #13
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    No, you could make a macro like assert does.

  14. #14
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    With malloc/free it's pretty easy:
    Code:
    #define malloc(size) mymalloc(size, _LINE__, __FILE__)
    #define free(ptr) myfree(ptr, _LINE__, __FILE__)
    Of course, make sure those macros are NOT in place when you define your mymalloc/myfree.

    I think with new/delete, you have to be a bit more imaginative. I can't come up with a simple solution right now. I will have a think about it tho'.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  15. #15
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Ah, paraphrazing Elysias suggestion:
    Code:
    struct FileLine
    {
        char *file;
        int line;
        FileLine(int l, char *f) : line(l), file(f) {};
    };
    
    #define new new(FileLine(__FILE__, __LINE__))
    Or something similar, at least.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  4. Suggestions on this C style code
    By Joelito in forum C Programming
    Replies: 11
    Last Post: 06-07-2007, 03:22 AM
  5. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM