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; Code: stack = new char[STACK_SIZE]; stack: 0xb7da6014 has value 3084541972 0xb7da6012 has value 3084541970 0xb7da6016 has value 3084541974 Right before ...

  1. #31
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Code:
    stack = new char[STACK_SIZE];
    stack: 0xb7da6014 has value 3084541972
    0xb7da6012 has value 3084541970
    0xb7da6016 has value 3084541974

    Right before
    Code:
    delete[] stack;
    stack: 0xb7da6014 has value 3084541972
    0xb7da6012 has value 3084541970
    0xb7da6016 has value 3084541974

  2. #32
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Sorry, is this "stack" the block of memory you actually pass as the pointer to "stack" in your thread, or is it some other form of stack?

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

  3. #33
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    You must monitor stack + SIZE_STACK * sizeof(char), not stack + 4.
    Data is written either at the end of the allocated memory or at the beginning (though the beginning is more likely).
    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.

  4. #34
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Quote Originally Posted by Elysia View Post
    There is std::stack and std::vector and std::tr1::smart_ptr. Try those before doing manual allocation.
    Ok, well I'm just copying the sample code that we were given to set up the ucontext_t. I also have other stacks that I set up the same way, only difference is that they are part of a struct, and this one isn't. I'll try using stack/vector/smart_ptr once I figure out how they fit in to what I'm doing.

  5. #35
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Quote Originally Posted by matsp View Post
    Sorry, is this "stack" the block of memory you actually pass as the pointer to "stack" in your thread, or is it some other form of stack?

    --
    Mats
    This is how the thread gets set up
    Code:
    cleanup = new ucontext_t;
    	getcontext(cleanup);
    	stack = new char[STACK_SIZE];
    	cleanup->uc_stack.ss_sp = stack;
    	cleanup->uc_stack.ss_size = STACK_SIZE;
    	cleanup->uc_stack.ss_flags = 0;
    	cleanup->uc_link = NULL;
    	makecontext(cleanup,(void(*)())((thread_startfunc_t)thread_finish),1,arg);

  6. #36
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    std::stack is basically a stack. You push onto it or pop something off.
    std::vector is a dynamic array. You can fill it with information and it will grow if the size is insufficient. It works like any C-style array.
    std::tr1::smart_ptr handles the pointers for you, saving you from calling delete. By handling the resource management, it gives much less change for leaks or errors.

    And do not cast function pointers. If done properly, a cast will not be necessary. If it does not compile, then you are not passing a compatible function.
    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. #37
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    And you create only one stack, yes?

    As Elysia says, maybe you need to check the memory immediately AFTER the stack too.

    Also, I think ss_sp should point at the BASE of the stack, which would be ((stack + STACK_SIZE) & ~15) [aligned to 16 bytes at no extra charge].

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

  8. #38
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    STACK_SIZE * sizeof(char) gets printed as 262144 so that converted to hex is 40000.

    stack starts at 0xb7d13014
    +40000 is 0xb7d53014 with value 3083837460
    -40000 is 0xb7cd3014 with value 3083313172

    values don't change

  9. #39
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Quote Originally Posted by matsp View Post
    And you create only one stack, yes?

    As Elysia says, maybe you need to check the memory immediately AFTER the stack too.

    Also, I think ss_sp should point at the BASE of the stack, which would be ((stack + STACK_SIZE) & ~15) [aligned to 16 bytes at no extra charge].

    --
    Mats
    I create several stacks, one for each thread.

  10. #40
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    Just for fun I moved the delete of the stack to right after I create it and no segfault, so I guess that means that it gets corrupted somewhere in between when I make it and when I delete it, as opposed to being screwed up before I make it.

  11. #41
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by jcafaro10 View Post
    Valgrind is giving me something interesting.

    Process terminating with default action of signal 11 (SIGSEGV)
    Access not within mapped region at address 0x0

    It's pointing to this though:
    Code:
    max_disk_queue = atoi(argv[1]);
    This is in a completely different place though and happens way before. Also, it doesn't actually segfault at that line.
    Are you sure you're in sync? Have you done a clean rebuild with -g? If that line of code has truly already executed, there's no reason for valgrind to complain about it.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #42
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    I think I know why it's segfaulting. For those not familiar with ucontext_t, theres a uc_link parameter that says, when a thread (ucontext_t) is finished executing, execute this thread (ucontext_t) next. All threads I create, I want to execute my cleanup function at the end. The cleanup function is it's own ucontext_t. When there are no more remaining threads, I want to delete my cleanup thread and exit the program. The problem is, I suppose, I'm trying to delete the stack belonging to the cleanup thread, while I'm currently running the cleanup thread.

    Basically the last chain of events are:
    Thread Z finishes executing
    Thread Z swaps context with Cleanup Thread
    Cleanup Thread adds Z to list of Threads that will be deleted
    Cleanup Thread sees that there are no more active threads
    Cleanup Thread deletes all of the threads
    Cleanup Thread tries to delete it's own stack --> segfault
    Last edited by jcafaro10; 02-04-2009 at 11:44 AM.

  13. #43
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,915
    ...Then it would not segfault on the delete, but the accessing of freed memory...
    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. #44
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,263
    Quote Originally Posted by Elysia View Post
    ...Then it would not segfault on the delete, but the accessing of freed memory...
    But the result would be the same. Suppose that freeing the memory unmaps it, so that those addresses will cause a segfault. You call delete -- it pushes a return address onto the stack. It frees the stack. In order to return, it must read the stack, which has just been deallocated -- boom.

    It's not the same sort of failure as when the heap management walks off into neverland, but it would sure look like it.

    Having said all that, I think it's unlikely that the pages are unmapped when the memory is freed, unless these stacks are rather large. Honestly, my hunch is that something somewhere else is buggy, and trashing the heap. It might not have anything to do with the stack at all.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  15. #45
    Registered User
    Join Date
    Jul 2007
    Posts
    186
    It makes sense I guess because there isn't really any difference between this stack and the stack associated with any of the other thread contexts. I can delete all of those stacks just fine. The only difference is, I'm deleting them from a different context. When I try and delete the stack belonging to the context I'm running on, I segfault. Nothing can be accessing the stack after I delete it because I call exit(0) so perhaps it's something else. I'll look into it more. Thanks for the help all, I appreciate it

Page 3 of 4 FirstFirst 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, 07:22 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. linked list recursive function spaghetti
    By ... in forum C++ Programming
    Replies: 4
    Last Post: 09-02-2003, 03:53 PM
  4. Memory handler
    By Dr. Bebop in forum C Programming
    Replies: 7
    Last Post: 09-15-2002, 05:14 PM
  5. multiple indirection...
    By doubleanti in forum C++ Programming
    Replies: 7
    Last Post: 08-31-2001, 11:56 AM

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