Can't delete memory

This is a discussion on Can't delete memory within the C++ Programming forums, part of the General Programming Boards category; I have a stack that I've allocated on the heap Code: char* stack Code: stack = new char[STACK_SIZE]; But later ...

  1. #1
    Registered User
    Join Date
    Jul 2007
    Posts
    186

    Can't delete memory

    I have a stack that I've allocated on the heap

    Code:
    char* stack
    Code:
    stack = new char[STACK_SIZE];
    But later on in the code I try to delete stack and I get a segfault. What could cause me to not be able to delete this?

    I'm using the debugger and the memory address of stack doesn't change between when I make it and when I delete it.
    Last edited by jcafaro10; 02-03-2009 at 10:15 PM.

  2. #2
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,167
    You meant
    Code:
    delete[] stack;
    ?

    That should work.

    Are you sure that's where you are getting the segfault? Is that what the debugger backtrace say?

  3. #3
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Why delete[]? I've never seen that notation before. I've also called delete on other stacks in the program using delete without any problem. The error I'm getting is Segmentation Fault, that's what prints in the console.

    Using delete[] vs delete doesn't change the segfault

  4. #4
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,418
    segfaults on delete almost always mean you've trashed the memory pool somewhere with a buffer overrun.

    Try valgrind if you're on linux.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  5. #5
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,167
    malloc/free
    new/delete
    new[]/delete[]

    don't mix and match them.

    From what I heard, Linux doesn't really care, but it is undefined behaviour and there are systems out there that do care (not sure about Windows).

    It's unlikely the problem.

    I'm assuming you are using Linux.

    My guess is you are accessing stack after it has been free'd. Try to compile your code with debugging symbols and run your code through GDB.

    Code:
    $g++ -g asdf.cpp -o asdf
    $gdb asdf
    (gdb) run
    ...
    Segmentation Fault
    (gdb) backtrace
    ... it should give you where the crash occured, and the function call stack at that time
    Failing that, run your code through Valgrind (a memory error debugger). It's like GDB, but will catch just about every memory error (accessing a block after free'd, double free, memory leak, accessing past the end of allocated blocks, etc).

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    On Windows, you will get errors if you delete with delete instead of delete[] when you allocate with new[].
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Thanks for the responses. I am on linux and I allocated using new like so:
    Code:
    char* stack = new char[STACK_SIZE];
    I've traced through with gdb and the segfault occurs right at the delete of the stack. I'll try valgrind. I've never used it but I see it as an option in KDevelop so I'll give it a shot. The weird thing is, I can see the memory that is allocated to the stack when I allocate it, and it doesn't change at all.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Yes, most likely it will fault when you delete, but it's also most likely CAUSED by some other piece of code writing to some part of memory that it shouldn't be using.

    --
    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.

  9. #9
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    So to delete it, firstly you must use
    delete[] stack;
    And if it still does not work, it means you have corrupted memory somewhere.
    The easiest way to detect such errors is to use breakpoints that breaks whenever some 4 bytes or so before the allocated address and after the allocated amount is written to.
    That should allow you to see the culprit which writes to that area of memory when it should not.
    If gdb can do this or how it can is not my area of expertise, however.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #10
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Hmm.. Any ideas for tracking things that write to specific memory ranges?

  11. #11
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by jcafaro10 View Post
    Hmm.. Any ideas for tracking things that write to specific memory ranges?
    Yes, valgrind is exactly intended for this. But the memory allocation immediately before the stack is the most likely candidate.

    --
    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 carrotcake1029's Avatar
    Join Date
    Apr 2008
    Posts
    398
    Well since you are on linux, try what Salem suggested, use valgrind. Compile your code with the -g flag and run "valgrind --tool=memcheck ./program", and that should get you started. I am to the point now whenever I use malloc or any other derivative function, I always make sure I am doing it right with valgrind.

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Oh yes, before that, check if the pointer itself is valid.
    Again, use a breakpoint to break when and if the pointer changes.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    How do I determine if the pointer is valid? GDB+KDevelop tells me the memory address of the pointer. When I allocate the stack the pointer gets a memory address and it keeps that memory address so I don't think that's the problem.

    Something that is a little curious is, on my watch list it says stack, and gives me a hex memory address, and under that is *stack and thats got 0x0. I'm not sure what that means though.

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Quote Originally Posted by jcafaro10 View Post
    When I allocate the stack the pointer gets a memory address and it keeps that memory address so I don't think that's the problem.
    That is what I mean.
    Operator new always returns a valid memory address (or throws). So if the pointers value is never changed from the point it is assigned from new, then you can be sure it's valid.
    Some debuggers can also check if a pointer points to a valid memory location. But it's best to know if the original value is preserved since this is what you must delete.

    Something that is a little curious is, on my watch list it says stack, and gives me a hex memory address, and under that is *stack and thats got 0x0. I'm not sure what that means though.
    *stack is the value of the first allocated char of your array.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 4 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assignment Operator, Memory and Scope
    By SevenThunders in forum C++ Programming
    Replies: 47
    Last Post: 03-31-2008, 06:22 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 12:57 AM
  3. linked list recursive function spaghetti
    By ... in forum C++ Programming
    Replies: 4
    Last Post: 09-02-2003, 02:53 PM
  4. Memory handler
    By Dr. Bebop in forum C Programming
    Replies: 7
    Last Post: 09-15-2002, 04:14 PM
  5. multiple indirection...
    By doubleanti in forum C++ Programming
    Replies: 7
    Last Post: 08-31-2001, 10:56 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21